Automated banking machine that operates responsive to data bearing records

ABSTRACT

An automated banking machine operates responsive to data read from data bearing records to cause financial transfers. The machine includes a card reader that operates to read card data from user cards. The card data corresponds to financial accounts. The automated banking machine includes a cash dispenser and the machine carries out transaction functions for consumers including dispensing cash. The automated banking machine may generate an operating system account password from separate portions of the password acquired from a portable storage device and a local data store.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.11/421,120 filed May 31, 2006, which is a continuation-in-part of U.S.application Ser. No. 10/746,276 filed Dec. 26, 2003, which claimsbenefit of U.S. provisional application Ser. Nos. 60/436,883 filed Dec.26, 2002; 60/436,784 filed Dec. 26, 2002; 60/436,780 filed Dec. 26,2002; 60/436,882 filed Dec. 26, 2002; 60/436,779 filed Dec. 26, 2002;60/436,719 filed Dec. 26, 2002; 60/436,908 filed Dec. 26, 2002;60/436,832 filed Dec. 26, 2002; 60/436,831 filed Dec. 26, 2002 and60/487,754 filed Jul. 15, 2003. U.S. application Ser. No. 11/421,120also claims benefit under 35 U.S.C. 119(e) of U.S. provisionalapplication Ser. Nos. 60/687,132 filed Jun. 3, 2005; 60/687,176 filedJun. 3, 2005; 60/687,175 filed Jun. 3, 2005; 60/687,268 filed Jun. 3,2005; 60/687,263 filed Jun. 3, 2005; 60/687,131 filed Jun. 3, 2005; and60/687,571 filed Jun. 3, 2005. All of these applications are herebyincorporated herein by reference.

TECHNICAL FIELD

This invention relates to automated banking machines that are operatedresponsive to data read from bearing records such as user cards to causefinancial transfers, and which may be classified in U.S. class 235,subclass 379.

BACKGROUND ART

Automated banking machines may include a card reader that operates toread data from a bearer record such as a user card. The automatedbanking machine may operate to cause the data read from the card to becompared with other computer stored data related to the bearer. Themachine operates in response to the comparison determining that thebearer is an authorized system user to carry out at least onetransaction which is operative to transfer value to or from at least oneaccount. A record of the transaction is also commonly printed throughoperation of the automated banking machine and provided to the user.Automated banking machines may benefit from improvements.

OBJECTS OF EXEMPLARY EMBODIMENTS

It is an object of an exemplary embodiment to provide an automatedbanking machine at which a user may conduct transactions.

It is a further object of an exemplary embodiment to provide anautomated banking machine which is more secure.

It is a further object of an exemplary embodiment to provide anautomated banking machine that has increased resistance to beingattacked by an unauthorized user.

It is a further object of an exemplary embodiment to provide anautomated banking machine which is operative to prevent unauthorizedmodifications to the ATM from enabling the theft of cash or transactioninformation.

Further objects of exemplary embodiments will be made apparent in thefollowing Detailed Description of Exemplary Embodiments and the appendedclaims.

The foregoing objects may be accomplished in an embodiment of anautomated banking machine. A common type of automated banking machineused by consumers is an automated teller machine. Automated tellermachines enable customers to carry out banking transactions. Commonbanking transactions that may be carried out with automated tellermachines include the dispensing of cash, the making of deposits, thetransfer of funds between accounts, the payment of bills and accountbalance inquiries. The types of banking transactions a customer cancarry out are determined by capabilities of the particular bankingmachine and the programming of the institution operating the machine.Other types of automated banking machines may allow customers to chargeagainst accounts or to transfer funds. Other types of automated bankingmachines may print or dispense items of value such as coupons, tickets,wagering slips, vouchers, checks, food stamps, money orders, scrip ortraveler's checks. For purposes of this disclosure an automated tellermachine, an automated banking machine, or an automated transactionmachine shall encompass any device which carries out transactionsincluding transfers of value.

Automated teller machine cases may have a plurality of designs andshapes. For example, automated teller machines may include a largereinforced security chest or safe which is capable of enclosing both acash dispenser mechanism and a computer which operates the cashdispenser as well as the other devices of the automated teller machine.In other automated teller machines, the computer of the automated tellermachine may be located outside the chest, although still within a lockedenclosure or fascia. Unfortunately, an enclosure or fascia may be lesssecure than a chest and may be pried or cracked open. As a result,computers or other automated teller machine devices located outside thechest may have an increased risk of being modified or hacked byunauthorized users. Such modifications may compromise the security ofthe automated teller machine and improperly cause the automated tellermachine to dispense cash or otherwise transfer value to the unauthorizeduser.

In addition, automated teller machines are connected to at least onenetwork. Such networks may include private networks which include one ormore automated teller machine host banking systems. Such networks mayalso include public networks such as the Internet. Automated tellermachines may also use standard Internet protocols to communicate withautomated teller machine host banking systems. Such standard protocolsmay include network protocols such as TCP/IP. As a result, automatedteller machines which use TCP/IP may be attacked with the same types ofhacking tools used to attack web sites, and other types of computersystems on the Internet.

Once an unauthorized user has gained access to the computer and/or otherhardware of an automated teller machine, whether by networkcommunication or physical access to the inside of an automated tellermachine, the unauthorized user may have the opportunity to stealinformation from the automated teller machine. For example anunauthorized user may attempt to have unauthorized software (i.e.viruses, worms, sniffer programs) execute on the automated tellermachine which is operative to capture transaction information such asaccount numbers, personal identification numbers, and other secretinformation. As a result, there further exists a need for an automatedbanking machine which has increased protection against the theft oftransaction information. In addition, such unauthorized software couldattempt to cause a cash dispenser to dispense cash improperly or causeother devices to operate in an unauthorized manner. As a result, therefurther exists a need for an automated banking machine which hasincreased protection against unauthorized software taking control of themachine.

As discussed herein an automated banking may also be referred to as anautomated teller machine (“ATM”), an automated transaction machine or aself service terminal. The automated banking machine may include outputdevices such as a display screen and receipt printer. The automatedbanking machine may further include input devices such as a touchscreen, keyboard, keypad, function keys, and a card reader. Theautomated banking machine may further include transaction functiondevices such as a cash dispenser mechanism for sheets of currency, adepository mechanism, currency recycler, and other transaction functiondevices which are used by the machine in carrying out bankingtransactions including transfers of value.

In this described embodiment the automated banking machine may includeat least one computer. The computer may be in operative connection withthe output devices and the input devices, as well as with the cashdispenser mechanism, depository mechanism and other physical transactionfunction devices in the banking machine. The computer may further beoperative to communicate with a host system located remotely from themachine.

In embodiments of the automated banking machine, the computer mayinclude software components that are executable therein. The softwarecomponents of the automated banking machine may be operative to causethe computer to output user interface screens through a display deviceof the machine. The user interface screens may include consumer screenswhich provide a consumer with information for performing consumeroperations such as banking functions with the machine. The userinterface screens may further include service screens which provide anauthorized user servicing the machine with information for performingservice and maintenance operations with the machine. In addition, themachine may include software components operative in the computer forcontrolling and communicating with hardware devices of the machineincluding the input devices, output devices and the transaction functiondevices.

In an embodiment the automated banking machine includes a plurality ofcomponents which may correspond to two or more of the previouslydescribed input devices, output devices, transaction function devices,and/or software components. The plurality of components may include afirst component and a second component. The first and second componentsare operative to securely communicate with each other. Such securecommunications may include passing encrypted information between eachother which is associated with a transaction function being performed bythe machine. Such a transaction function may correspond to the dispenseof cash or any other function performed by the automated bankingmachine. The information may be encrypted and decrypted with a secretkey such as a DES, AES or other symmetrical key known to both the firstand second components. The information may also be encrypted anddecrypted with an asymmetric public/private key pair such as RSA. Theencrypted information may correspond to account numbers, personalidentification numbers (PINs), status information, error information,encryption keys, software function or event calls, operational commands,or any other type of information associated with the operation of themachine which may be passed between hardware and/or software componentsof an automated banking machine for purposes of performing a transactionfunction.

When the secure communication between the first and second components isbeing established, the second component of the embodiment may beoperative to authenticate the identity of the first component in orderto prevent the possibility of a “man in the middle” hacking attack. Sucha “man in the middle” hacking attack may correspond to a software virus,worm, or an imposter hardware device or software component which isconstructed to intercept secure communications between components. Inone scenario of a “man in the middle” attack, the rogue software orhardware component may function as a router which filters the intendedcommunications between the first and second components. Such filteringmay enable the rogue component to acquire the secret key or keys used todecrypt the information being communicated between the first and secondcomponents. Such filtering may also enable a rogue component to replaysampled communications to cause a hardware device or other component torepeat a function.

The embodiment of the present invention may be operative to prevent a“man in the middle” attack by requiring the first component toauthenticate itself to the second component. Examples of methods andsystems usable by components to authenticate each other in an ATM areshown in U.S. application Ser. No. 10/746,276 filed Dec. 26, 2003 whichis hereby incorporated by reference herein. U.S. application Ser. No.10/746,276 discloses examples for establishing secure communicationsbetween components in which the computer of an ATM may or may notinclude a trusted platform module (TPM). In an embodiment in which thecomputer includes a TPM, the ATM may be operative to establish a trustedplatform (TP) using the TPM and associated software which complies witha trusted computing platform or base specification. The trusted platformmay be used to perform all or portions of the cryptographic functionsfor the software and hardware components of the ATM to establish securecommunications between the components. In addition, the computer of theATM may use the TPM to establish secure communications with a remotecomputer such as a host banking system. Further, the TPM may be used toenable an ATM component such as a cash dispenser to verify that thesoftware components controlling the cash dispenser are authorized to doso. In addition, the TPM may be used to generate account passwordsusable by the ATM to log into an operating system login account forpurposes of configuring and servicing the machine.

For example, an embodiment of an ATM may be operative to carrying out amethod which comprises through operation of at least one computer in theATM, using a TPM in the ATM to establish encrypted communication with atransaction function device in the ATM. In this described embodiment,the ATM may include a cash dispenser. Once the encrypted communicationis established, the method may further comprise the at least onecomputer and at least one processor in the transaction function device,sending encrypted operational data between the computer and thetransaction function device which is operative to enable the ATM toperform a function.

In this described embodiment, the step of establishing the encryptedcommunication may comprise the at least one computer, using the TPM toencrypt at least one key such as a session key to form encrypted keydata. The method step of establishing the encrypted communication mayfurther comprise the at least one computer, causing the encrypted keydata to be communicated from the at least one computer to the at leastone transaction function device. In addition, the method step ofestablishing the encrypted communication may comprise the at least oneprocessor in the at least one transaction function device, decryptingthe at least one key from the encrypted key data.

The at least one computer and the at least one processor in the at leastone transaction function device are operative to use the key to encryptand decrypt the operational data sent therebetween. The key maycorrespond to a symmetrical key usable with cryptographic algorithmssuch as DES, triple DES, AES, or any other encryption/decryptionoperation capable of being performed by the computer using the TPM andthe processor in the transaction function device. The at least onecomputer may use the TPM to securely store the key in either the TPM oran encrypted file or other location external to the TPM. The at leastone processor of the transaction function device may also store the keyin a data store of the transaction function device.

In this described embodiment, the step of communicating the encryptedoperational data may comprise at least one of the TPM and the at leastone computer encrypting the operational data using the at least one keyand sending the encrypted operational data to the transaction functiondevice. In addition, the communicating step may comprise the at leastone processor in the at least one transaction function device decryptingthe operational data using the at least one key. Once the operationaldata is decrypted, the at least one processor may enable the at leastone transaction function device to operate responsive to the operationaldata.

When the transaction function device corresponds to a cash dispenser,the cash dispenser may be adapted to dispense cash responsive to theoperational data. The operational data may specify an amount of cash todispense and other parameters usable by the cash dispenser to operatesuch as the numbers and denominations of bills to dispense. In addition,the operational data may correspond to commands to perform diagnosticoperations and/or commands to return status information. In thisdescribed embodiment, the operational data communicated to thetransaction function device in the ATM may correspond to any commands,parameters, configuration data, or any other communication the device isadapted to receive for use with carrying out operations in the ATM.

In the described embodiment, the method may further comprise the leastone processor in the at least one transaction function device, causingthe at least one transaction function device to operate. The operationaldata communicated in the method may be associated with the operation ofthe at least one transaction function device. The communication step maythen include the at least one processor in the at least one transactionfunction device encrypting the operational data using the at least onekey and sending the encrypted operational data to at least one computer.The communication step may then include at least one of the TPM and theat least one computer, decrypting the operational data using the atleast one key. Once the operational data has been decrypted, the methodmay include the at least one computer, causing the ATM to perform atleast a portion of a transaction function responsive to the operationaldata.

In this described embodiment, the operational data sent from thetransaction function device may include status information, inputs,error messages, diagnostic information, commands, messages, or any otherdata that the transaction function device may be capable ofcommunicating to the computer in the ATM. For example, if thetransaction function device corresponds to a cash dispenser, theoperational data may be representative of whether cash was successfullydispensed by the cash dispenser. Also, for example, if the transactionfunction device corresponds to an encrypting pin pad (EPP), theoperational data sent from the EPP may include inputs representative ofan amount of cash to withdraw, a PIN, menu selections, or any otherinformation capable of being received through operation of the keypad ofthe EPP.

In the described embodiment of the method, the at least one computer inthe ATM may be responsive to the operational data received to continuecarrying out a transaction. Such a transaction may requirecommunications with a host banking system; thus the method may includethe at least one computer sending a message to a host banking systemresponsive to the operational data. Such a message may include theoperational data. If an authorization is needed to complete thetransaction function, the host banking system may then communicate anauthorization message to the ATM and the at least one computerresponsive to the authorization may carry out the requested transactionfunction such as dispensing cash, for example.

In this described embodiment of the method, the transaction functiondevice may comprise a cash dispenser, a depositor, a card reader, and anEPP. However, it is to be understood that in alternative embodiments themethod may be carried out with other types of devices in an ATMincluding input devices, output devices, or any other device in which itmay be desirable to encrypt information passed to or from the device.Also in this described embodiment, the step of establishing encryptedcommunication may include a key transport mechanism carried out betweenthe at least one transaction function device and the at least onecomputer of the ATM which corresponds to Key Transport Mechanism 5 ofISO IEC 11770-3. However, in alternative embodiments other key transferprotocols may be used.

In the above-described method of establishing encrypted communicationsbetween the computer in the ATM and a transaction function device in theATM, the TPM is used to carry out portions of the method steps. Forexample, the TPM may be used to perform portions of the cryptographicencryption and decryption operations. The TPM may also be used tosecurely store the sessions keys, private keys and/or any otherinformation usable to carry out the method steps. The TPM may also beused to digitally sign data and/or authenticate signed data.

A TPM may also be used to establish encrypted communication between theATM and a remote server such as a host banking system. For example, anembodiment of such a method may include the at least one computer in anATM storing a digital certificate in the ATM, which digital certificatecomprises a public key. The method may further include the at least onecomputer in the ATM using the TPM to store a private key associated withthe public key in the ATM. The method may include the at least onecomputer in the ATM, establishing a secure communication session betweenthe ATM and a remote server through use of the digital certificate andthe private key.

If the remote server corresponds to a host banking system, the methodmay further comprise the at least one computer in the ATM using thesecure communication session to receive an authorization to dispensecash through operation of a cash dispenser in the ATM and responsive tothe authorization, dispensing cash through operation of the cashdispenser.

In this described embodiment, the step of establishing a securecommunication session may include performing a secure sockets layer(SSL) protocol, a transport layer security (TLS) protocol, or a protocolassociated with a virtual private network (VPN) connection that requiresuse of a private asymmetric key for a public key encryption algorithmsuch as RSA.

The at least one computer in the ATM may use the TPM to generate thepublic key and private keys. Once the public and private key pair isgenerated, the at least one computer in the ATM may cause the digitalcertificate to be created. This may include the ATM sending acertificate request message to a certificate authority.

A further embodiment of the ATM may include a method of using the TPM toenable devices in the ATM such as a cash dispenser to authenticate asoftware stack which is operative to control or otherwise communicatewith the device. In this manner the device in the ATM can verify thatthe software used to interface with the device has not been altered orotherwise updated in a manner which is not authorized by the deviceitself. For example with respect to a device such as a cash dispenser,the method may comprise having a TPM in the ATM, generate at least onedigitally signed measurement for at least one software componentexecuting in at least one computer of the ATM. The method may furthercomprise at least one processor in the cash dispenser in the ATMauthenticating the at least one digitally signed measurement. Inaddition, the method may comprise dispensing cash through operation ofthe cash dispenser responsive to the measurement being authenticated bythe at least one processor in the cash dispenser.

In this described embodiment, the method may further comprise storing atleast one reference measurement in at least one data store of the cashdispenser. Such a reference measurement may have been generated for anapproved version of the software which must be executing in the computerof the ATM prior to the cash dispenser permitting cash to be dispensedresponsive to the software component. The step of authenticating the atleast one digitally signed measurement may include verifying that the atleast one measurement included in the at least one digitally signedmeasurement corresponds to the at least one reference measurement. Thestep of authenticating the at least one digitally signed measurement mayalso include authenticating the digital signature of the digitallysigned measurement using a public key associated with the TPM. In thisdescribed embodiment, a current measurement of a software component maybe generated by using the TPM to create a hash or digest of the softwarecomponent at the point in time the software component is initiallyexecuted in the computer of the ATM. The reference measurement may alsocorrespond to a hash of the software component. The hash from thecurrent measurement must be identical to the hash of the referencemeasurement to successfully validate the current software component.

To decrease the opportunity for the previously described “man in themiddle” attack to gain unauthorized control of the cash dispenser, themethod may further include the cash dispenser sending at least onerandom number from the cash dispenser to the at least one computer. Thisrandom number may be appended to at least one hash of the at least onesoftware component generated using the TPM and the combination of the atleast one random number and the at least one hash may be signed usingthe TPM to form the at least one digitally signed measurement. The stepof authenticating the at least one digitally signed measurement may theninclude the at least one processor in the cash dispenser determiningthat the at least one random number received in the at least onedigitally signed measurement corresponds to the at least one randomnumber originally sent by the cash dispenser.

The at least one software component may be comprised of a plurality ofsoftware applications executing in the at least one computer which areadapted to control the operation of the cash dispenser. Examples of suchsoftware components may include cash dispenser device drivers, terminalcontrol software applications, diagnostic software, XFS serviceproviders, or any other software which is involved with communicatingwith the cash dispenser. In this described embodiment, the at least onecomputer may cause the at least one reference measurement to begenerated for the at least one software component and to be sent to thecash dispenser for storage therein. To further enhance the security ofthe method, the chest or safe of the ATM which includes portions of thecash dispenser therein may further include at least one input devicemounted therein. The at least one input device may correspond to abutton, switch or other input device which is only accessible to a userwhen a chest door of the chest is in an open position. The cashdispenser may be operative to only accept initial or updated referencemeasurements for storage therein when an input is received throughoperation of the input device by the user. If the input devicecorresponds to a button, the cash dispenser is operative to only acceptinitial or updated reference measurements in response to the button inthe chest being pressed by the user.

In an alternative embodiment of the method, the at least one computer inthe ATM may be operative to access the at least one referencemeasurement from a remote server rather than by generating the referencemeasurement locally from the software component. The hashes for thereference measurements may be generated using a reference platform. Theremote server may include the reference measurements for a plurality ofdifferent software components and versions of software components. Theremote server may also be accessible by a plurality of different ATMswhich may comprise different combinations of software components and/orversions of the software components.

In a further alternative embodiment of the method, the softwarecomponent setup programs and/or packages may include the referencemeasurements therewith. When the software components are initiallyinstalled on the ATM, the setup programs may install the referencemeasurements in addition to the software components on the ATM. When thedescribed input device in the chest is operated by a user, the ATM maybe operative to send the reference measurements to the cash dispenserwhich correspond to the software components associated with the cashdispenser.

In the described embodiment, the reference measurements may also bedigitally signed. If the reference measurements are generated using theTPM, the reference measurements may be signed by a private keyassociated with the TPM. If the reference measurements are retrievedfrom a remote server or are acquired from the setup programs or packagesfor the software components, the reference measurements may be digitallysigned by the private key of an entity trusted by the ATM and/or cashdispenser.

When the reference measurements are sent to the cash dispenser, themethod may include the at least one processor, authenticating thedigital signatures of the reference measurements. For purposes ofauthenticating the current measurements and/or the referencemeasurements, the method may include the at least one computer sending apublic key associated with the TPM to the cash dispenser for storagetherein. The public key may be sent within a digital certificateassociated with the TPM. The method may also include the at least oneprocessor of the cash dispenser authenticating the digital certificateusing a public key of a certificate authority stored in at least onedata store of the cash dispenser. In embodiments where the referencemeasurements are not digitally signed using the TPM, the cash dispensermay include a data store which includes stored therein a public key ofthe entity which digitally signed the reference measurements. The publickey of the trusted entity may be used by the at least one processor inthe cash dispenser to authenticate the reference measurement while thepublic key of the TPM may be used by the at least one processor in thecash dispenser to authenticate the current measurements.

When the software components are updated, or otherwise modified fromtheir previously approved form, the current measurements generated usingthe TPM of the modified software components will not match the referencemeasurements. In this situation, the method may include the at least oneprocessor in a cash dispenser, determining that at least one digitallysigned measurement received from the at least one computer is not valid;and responsive to this determination, the method may include sending afault message to the at least one computer.

In an embodiment, during the initialization of the cash dispenser or atother times, the method may include the processor sending a challengemessage from the cash dispenser to the at least one computer, such achallenge message may include the above described random number. Inresponse to receiving the challenge method, the at least one computermay send the current digitally signed measurements for the softwarecomponents to the cash dispenser for authentication by the at least oneprocessor in the cash dispenser.

In this described method, the cash dispenser is operative to verify thatthe approved software components associated with the cash dispenser havenot been altered. However, to prevent an additional software component(e.g. virus, worm) from accessing or using one of the approved andauthenticated software components (e.g. a device driver) the approvedsoftware components may be operative to lock themselves so as to onlypermit access to the software components from other approved softwarecomponents.

A further embodiment involving an ATM may include a method and systemfor configuring the ATM to be capable of authenticating approved cashdispensing software components. Such a method may comprise at least oneof installing and updating a plurality of software components in a datastore of the at least one computer of an ATM. At least one of thesoftware components may be operative to control the operation of thecash dispenser.

As described previously, the at least one computer of the ATM may beoperative to use the TPM to generate a current measurement of the atleast one software component when the at least one software componentexecutes in the at least one computer. However, as not all of theplurality of software components are associated with the operation of acash dispenser, the method may further comprise providing at least oneinput through an input device of the ATM which causes the at least onecomputer to identify which of the plurality of software componentscorresponds to the at least one software component that is operative tocontrol the cash dispenser. The computer of the ATM may be adapted to beresponsive to the selection of the at least one software component toconfigure the cash dispenser to only authenticate the softwarecomponents which have been selected. As a result, only referencemeasurements for the selected software components need to becommunicated to the cash dispenser for storage therein and only currentmeasurements associated with the identified software components need tobe communicated to the cash dispenser when the cash dispenser issues achallenge message.

As discussed previously, the process of updating the cash dispenser withnew or updated reference measurements may include requiring a user toopen the chest of the ATM and press a button or other input device tocause the cash dispenser to accept the new reference measurements. In anembodiment of the ATM, the operation of the input device in the chestmay cause the cash dispenser to communicate a message to the computer ofthe ATM which requests the new reference measurements to be sent to thecash dispenser. However in alternative embodiments, the operation of theinput device in the chest may place the cash dispenser in a temporarymode in which it is capable of accepting new reference measurements whensent by the computer.

Although the above described method of authenticating softwarecomponents by a device in the ATM has been described using the exampleof a cash dispenser, it is to be understood that in alternativeembodiments other types of devices including other types of transactionfunction devices in the ATM may be adapted to carry out these methodsteps to validate one or more software components executing in thecomputer of the ATM.

Embodiments of an ATM may include a method and system for logging intoan operating system login account of the ATM using at least a portion ofa password supplied from a portable storage device placed in operativeconnection with the ATM by a user. In one embodiment, the portablestorage device may comprise a nonvolatile memory device such as a USBflash drive. In an alternative embodiment, the portable storage devicemay be comprised of a cryptographic token device which includes aprocessor capable of performing encryption and decryption operations oninformation stored in the device.

An embodiment of the method may comprise placing the portable storagedevice in operative connection with an ATM; operating an input device ofthe ATM to input a password such as a PIN associated with the portablestorage device; and causing the at least one computer to generate an ATMaccount password for an operating system login account of the at leastone computer in the ATM responsive to the PIN and the portable storagedevice. The step of generating the ATM account password may include theat least one computer, responsive to the PIN, causing at least one firstportion of the ATM account password stored on the portable storagedevice to be decrypted. In an embodiment of the method which uses aflash drive to log into the ATM, this step may include the at least onecomputer of the ATM performing the decryption using the TPM. In anembodiment of the method which uses a cryptographic token device to loginto the ATM, the processor of the cryptographic token device mayperform the decryption of the at least one first portion of the ATMaccount password after the ATM has forwarded the correct PIN to thedevice.

In addition, the step of generating the ATM account password may includecombining the decrypted at least one first portion of the ATM accountpassword and at least one second portion of the ATM account password togenerate the ATM account password. The at least one computer may thenuse the generated ATM account password to log into the ATM loginaccount. When the ATM is being manufactured or otherwise configured tobe capable of being logged-in in this manner, a method of setting up theATM may include creating the login account using the ATM accountpassword generated by the ATM as described above.

In this described embodiment, the at least one second portion of the ATMaccount password may be retrieved from a data store in the ATM such as aregistry or other storage location for data. When the ATM is initiallybeing configured to be logged in this manner, the at least one computermay randomly generate the at least one second portion of the ATMpassword and store the generated at least one second portion of the ATMpassword in the data store of the ATM.

The login account may correspond to an administrative account and/or anaccount with sufficient privileges to enable a user to access at leastone software component operative to cause at least one transactionfunction device of the ATM to operate. As discussed previously, examplesof transaction function devices in an ATM may include a cash dispenser,a depository; and EPP.

In embodiments of the ATM in which a flash memory device is used to loginto the account, the ATM may include a TPM, and the method may includedecrypting the at least one first portion of the ATM account passwordusing the TPM of the ATM. In this described embodiment, the at least onecomputer may receive at least one input (e.g. a PIN) through at leastone input device of the ATM. The at least one computer may also access acredential from the portable storage device and validate the input usingthe credential. The at least one computer may then decrypt the at leastone first portion of the ATM account password using the at least oneinput.

In this described embodiment, the at least one input may be inputtedthrough use of an input device such as the keypad of the ATM. The atleast one computer may generate a symmetrical encryption key using theat least one input and may decrypt the at least one first portion of theATM account password using the key generated from the input to producean intermediately encrypted at least one first portion of the ATMaccount password. The at least one computer may then decrypt theintermediately encrypted at least one first portion of the ATM accountpassword with another symmetrical key accessed using the TPM to producethe at least one first portion of the ATM account password. Thesymmetrical key accessed using the TPM may be stored in the TPMs (or infiles protected using the TPMs) of a plurality of different ATMs,enabling the same portable storage device to be used to log into each ofthe plurality of different ATMs according to the embodiments of thedescribed method.

To verify the input using the credential retrieved from the portablestorage device, the at least one computer may generate a hash from theat least one input and may verify that the generated hash matches afurther hash in the credential. In addition, the computer may verifythat a digital signature of the credential corresponds to the validsignature of a certificate authority trusted by the ATM.

In embodiments of the ATM in which a portable storage devicecorresponding to a cryptograph token device is used to log into theaccount, the ATM may not include a TPM. In this embodiment, the methodmay include receiving through an input device of the ATM at least oneinput and communicating the at least one input from the ATM to theportable storage device. Here the at least one input may correspond to apassword or PIN associated with the portable storage device. A processorin the portable storage device may be operative to validate the input.Responsive to validating the input, the processor in the portablestorage device may decrypt the at least one first portion of an ATMaccount password stored on the portable storage device and maycommunicate the decrypted at least one first portion of the ATM accountpassword from the portable storage device to the ATM.

To enable the ATM and the portable storage device to authenticate eachother, the method may include communicating at least one digitalcertificate from the portable storage device to the ATM. This digitalcertificate may include a public key associated with the portablestorage device. The digital certificate may be signed by a certificateauthority trusted by the ATM and the method may include at least onecomputer authenticating the signature on the digital certificate. Themethod may then include at least one computer generating andcommunicating a random number from the ATM to the portable storagedevice. When the random number is received from the ATM, the method mayinclude the processor in the portable storage device signing the randomnumber using a private key associated with the public key included inthe digital certificate. The processor in the portable storage devicemay then communicate the signed random number from the portable storagedevice to the ATM, and the at least one computer may verify thesignature using the public key. The at least one computer may alsoverify that the random number returned from the portable storage devicematches the random number sent from the ATM.

The at least one computer may then direct that the portable storagedevice decrypt the at least one first portion of the account passwordand communicate the at least one first portion of the account passwordto the ATM. The at least one computer may then combine the at least onefirst and the at least one second portions to produce the full ATMaccount password and log into the login account as discussed previously.

In these described embodiments, after the input from the user (e.g. PIN)is validated by either the at least one computer or the processor in theportable storage device, the method may include automatically generatingthe ATM account password and logging into the login account without anyfurther inputs from the user. However, in an alternative embodiment, theat least one computer may output a user interface through an outputdevice of the ATM which includes a selectable menu option associatedwith the function of logging into the login account. Responsive toreceiving a further input through at least one input device of the ATMcorresponding to the menu option, the at least one computer may proceedthrough the steps of logging into the login account of the ATM.

In the described embodiments, the credential and/or the certificatestored in the portable storage device may include at least oneidentification number which may be compared to a listing ofidentification numbers stored in a data store of the ATM. The at leastone computer may require the identification number of thecredential/certificate to be included in the listing before proceedingwith logging into the login account. However, if the listing correspondsto a list of revoked credentials/certificates, the at least one computermay verify that the identification number of the credential/certificateis not included in the listing before proceeding with logging into thelogin account.

In the described embodiments, once the at least one computer has loggedinto the login account the user may be capable of accessing softwarecomponents which operate, service, and/or configure software andhardware components in the ATM. Thus an embodiment of the method mayfurther include the at least one computer executing a software componentoperative to service or configure a transaction function device such asthe cash dispenser in the ATM or a software application such as asoftware component operative to enable customers to perform financialtransactions with the ATM.

As discussed previously a method of enabling an ATM to be capable ofusing portable storage devices to log into a login account may includerandomly generating and storing the at least one second portion of theaccount password in the ATM. This method may also include creatingand/or updating a login account of the operating system of the at leastone computer so that the login account is associated with the accountpassword. To perform this step, the method may include generating theaccount password from the first and second portions of the accountpasswords. Because the first portion of the account password is notgenerated by the ATM as is the second portion, the method may includeacquiring the at least one first portion from a portable storage deviceplaced in operative connection with a port of the ATM as discussedpreviously. Alternatively, the first portion of the account password maybe acquired from another source such as from a server in operativeconnection with the ATM. Once the first portion of the account passwordis acquired, the at least one computer may combine it with the randomlygenerated second portion to produce an account password usable forinitially setting or changing the password associated with the loginaccount.

For ATMs which include a TPM, the method may include storing thepreviously described symmetrical key usable to decrypt the first portionof the ATM account password in the TPM. The method may also includeinstalling the certificate of the certificate authority which is usableto authenticate the previously described credential or certificatestored on the portable storage device.

In this described method of configuring ATMs to be capable of logginginto a login account using a portable storage device, the method mayalso include configuring a plurality of portable storage devices to havestored thereon the encrypted at least one first portion of the accountpassword. For a portable storage device that corresponds to a flashdrive the method steps of configuring the portable storage device mayinclude storing a credential on the flash drive which is usable tovalidate a PIN capable of being used to decrypt the at least one firstportion of the account password. This method may include: generating acredential which includes a hash of the PIN; having the credentialsigned by a certificate authority; and storing the credential on theportable storage device. This method may also include encrypting the atleast one first portion of the ATM account password with a symmetricalkey that is also stored in the TPMs of a plurality of ATMs to form anintermediately encrypted at least one first portion of the accountpassword. The method may also include generating a further symmetricalkey from the PIN and encrypting the intermediately encrypted at leastone first portion of the account password with the key generated fromthe PIN. The resulting encrypted at least one first portion of theaccount password may then be stored on the portable storage device.

For a portable storage device that corresponds to cryptographic tokendevice with a processor, the method steps of configuring the portablestorage device may include causing a processor in the portable storagedevice to generate a public key and a private key pair. The public keymay then be incorporated into a digital certificate signed by acertificate authority and the digital certificate may be stored on theportable storage device. The method may further include causing the atleast one first portion of an ATM account password to be stored on theportable storage device in an encrypted form capable of only beingdecrypted through operation of the processor in the portable storagedevice.

Embodiments of an ATM may include a method and system for ensuring thatcomponents in the ATM have not been modified, updated, altered, orotherwise compromised prior to enabling the ATM to boot into a fullyfunctional state. Such a method may include through operation of a TPMincluded with at least one computer in the ATM, verifying that at leastone component of the ATM has not been altered and responsive to thisdetermination enabling the machine to dispense cash through operation ofa cash dispenser in the ATM.

Embodiments of an ATM may also include using the processor in the EPP todecrypt other information besides keys sent from a host banking systemto the ATM. Such information may include data in addition to keys,information such as screen data, configuration data, and/or any otherinformation usable by the ATM to operate. Such a method may includereceiving encrypted data from a host banking system with an automatedbanking machine, wherein the automated banking machine includes at leastone computer, a cash dispenser, and an EPP; and the EPP includes atleast one processor. The method may further include decrypting the datathrough operation of the at least one processor of the EPP; sending thedecrypted data from the EPP to the at least one computer of theautomated banking machine; and responsive to the decrypted data, throughoperation of the at least one computer, causing the cash dispenser todispense cash.

In a further embodiment in which the decrypted data corresponds toscreen data, the method may include 1, receiving encrypted screen datafrom a host banking system with an automated banking machine, whereinthe automated banking machine includes at least one computer, a cashdispenser, at least one display device and an EPP; and the EPP includesat least one processor. This described method may also includedecrypting the screen data through operation of the at least oneprocessor of the EPP. The method may also include through operation ofthe at least one computer, causing the at least one display device toproduce a visual output corresponding to at least a portion of thescreen data.

In an embodiment of the banking machine that includes a TPM, thisdescribed method may further include, encrypting the decrypted data suchas the screen data using the TPM and storing the data encrypted with theTPM in at least one data store of the automated banking machine. Whenneeded to produce a visual user interface output through the displaydevice of the machine, the portions of the encrypted data correspondingto the desired screen data may then be selectively retrieved from the atleast one data store and decrypted with the TPM.

Although the above-described embodiments have included methods, it is tobe understood that further embodiments may include ATM systems and otherapparatuses operative to carry out the above-described method steps.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a perspective view representative of an embodiment of anautomated banking machine.

FIG. 2 is a schematic view of an embodiment of an automated bankingmachine.

FIGS. 3-6 show schematic views of embodiments of automated bankingmachines which comprise trusted platforms with trusted platform modules.

FIG. 7 is a schematic view showing a method for establishing securecommunications between components of an automated banking machine.

FIG. 8 is a schematic view showing a system and method of a transactionfunction device such as a cash dispenser operating to authenticatesoftware operative to control the cash dispenser.

FIG. 9 is a schematic view showing a method in which a portable storagedevice is used to authenticate a user logging into a login account ofthe operating system of the automated banking machine.

FIG. 10 is a schematic view showing an alternative method in which aportable storage device is used to authenticate a user logging into alogin account of the operating system of the automated banking machine.

FIG. 11 shows a schematic view of an electronic voting machine whichincludes a trusted platform with a trusted platform module.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Referring now to the drawings and particularly to FIG. 1, there is showntherein a perspective view of an embodiment of an automated bankingmachine 10. Here the automated banking machine 10 may include at leastone output device 34 such as a display device 12. The output device 12may be operative to provide a consumer with a user interface 18 that mayinclude a plurality of screens or other outputs including selectableoptions for operating the machine. The embodiment may further includeother types of output devices such as a receipt printer 20, statementprinter 21, speakers, or any other type of device that is capable ofoutputting visual, audible, or other sensory perceptible information.

The embodiment of the automated banking machine 10 may include aplurality of input devices 32 such as an encrypting pin pad (EPP) withkeypad 16 and function keys 14 as well as a card reader 22 and/or barcode reader 23. The embodiment of the machine 10 may further include oruse other types of input devices, such as a touch screen, microphone, orany other device that is operative to provide the machine with inputsrepresentative of user instructions or information. The machine may alsoinclude one or more biometric input devices such as a fingerprintscanner, an iris scanner, facial recognition device, hand scanner, orany other biometric reading device which may be used to read a biometricinput that can be used to identify a user.

The embodiment of the automated banking machine 10 may further include aplurality of transaction function devices which may include for examplea cash dispenser 24, a depository mechanism 26, a cash recyclermechanism, or any other type of device which is operative to performtransaction functions involving transfers of value.

FIG. 2 shows a schematic view of components which may be included or maybe in communication with the automated banking machine 10. In thisdescribed embodiment the input devices 32, output devices 34,transaction functions devices 36, and a computer 30 may be in supportingconnection with a housing 11 of the machine. A detailed example of anATM housing and associated components is shown in U.S. Pat. No.7,040,534 B2 of May 9, 2006 which is hereby incorporated herein byreference.

Embodiments of the automated banking machine 10 may be operative tocommunicate with a transaction processing server which is referred toherein as an ATM host banking system 42. Such an ATM host banking system42 may be operative to authorize the automated banking machine 10 toperform transaction functions for users such as withdrawing cash from anaccount through operation of the cash dispenser 24, depositing checks orother items with the depository mechanism 26, performing a balanceinquiry for a financial account and transferring value between accounts.

The computer 30 may be in operative connection with a plurality ofcomponents. Such components may include both hardware components 46 andsoftware components 40. The hardware components 46 may correspond to thepreviously described input device(s) 32, output device(s) 34, andtransaction function device(s) 36. In an embodiment, a transactionfunction device may be operative to perform a transaction function inresponse to at least one input through at least one of the inputdevices.

In an embodiment of an ATM, the software components may correspond toone or more terminal control software components that are operative inthe computer 30. The terminal control software components may beoperative to control the operation of the machine by both a consumer andan authorized user such as a service technician. For example suchterminal control software components may include applications whichenable a consumer to dispense cash, deposit a check, or perform othertransaction functions with the machine. In addition the terminal controlsoftware components may include applications which enable a servicetechnician to perform configuration, maintenance, and diagnosticfunctions with the machine.

In an embodiment of an ATM, both software components and/or hardwarecomponents may be operative to communicate information with each otherthrough the computer and/or through a communication system associatedwith the computer. Such information may be encrypted to protectconfidential information from threats of intruders. Examples of methodsand systems usable by components to authenticate each other in an ATMare shown in U.S. application Ser. No. 10/746,276 filed Dec. 26, 2003which is hereby incorporated by reference herein.

Embodiments of an automated banking machine such an ATM may include atrusted platform (TP) which may also be referred to as a trustedcomputing platform or a trusted computer base (TCB). FIG. 3 shows anembodiment of a trusted platform (TP) 300 for an ATM 310. The ATM 310may include a computer 312. The computer 312 may include a motherboardwith a Basic Input-Output System (BIOS) 316 or an Extensible FirmwareInterface (EFI). The computer 312 may further include a trusted platformmodule (TPM) 314 that complies with a trusted platform specificationsuch as the Trusted Computing Platform Alliance (TCPA) specification,Trusted Computing Group (TCG) specification, Microsoft next-generationsecure computing base (NGSCB) (formerly called Palladium), IntelLaGrande Technology, Microsoft Longhorn TPM Services Architecture, orother TP specification for establishing a trusted and secure computingenvironment.

In embodiments of an ATM, the TPM may be comprised of one or morecomputer chips integrated into the motherboard of the computer 312 orotherwise placed in operative connection with a computer processor ofthe ATM. An example of a TPM which may be used with embodiments of anATM includes a TPM SLD 9630 chip of Infineon Technologies AG which isbased on the TCPA Main Specification version 1.1b. In other embodimentsthe ATM may include a TPM which corresponds to other specifications fora TPM such as the Trusted Computer Group TPM 1.2 Specification or laterdeveloped specifications.

Also, in embodiments of an ATM, the TPM may correspond to Microsoft'sspecification for a security support component (SSC) for the MicrosoftNGSCB. In alternative embodiments, the TPM may also be incorporated intothe processor of the computer of the ATM, hardware card, or other devicein operative connection with the computer processor of the ATM.

As used herein, a TP corresponds to hardware and software components ofa computer that conform to a trusted platform specification such as theTCPA Main Specification version 1.1b, the TPM 1.2 specification, Intel'sLaGrande Technology Specification, Microsoft's NGSCB, Microsoft'sLonghorn TPM Services Architecture or another trusted platformspecification which uses a TPM.

As used herein, the TP may be described as being used to performfunctions which may require the use of a TPM. However, it is to beunderstood that in addition to the TPM, software associated with the TPMmay also be involved in the performance of functions for the TP. Suchsoftware many include a trusted portion or kernel of the operatingsystem such as a “nexus” in Microsoft's NGSCB specification. Suchsoftware may further include a trusted application, nexus computingagent (NCA), protected applet, application programming interface (API),software stack, or other software component that enables the TP toperform the described function. As used herein and in the claims,references to using a TP to perform a particular cryptographiccalculation, authentication, or other function may include the use ofthe TPM chip and/or other software or hardware components which comprisethe TP such as a nexus or NCA.

The ATM 310 shown in FIG. 3 includes a TP 300 that conforms to the TCPAMain Specification Version 1.1b. Here the TP of the ATM 310 may includea TPCA Software Stack (TSS) 318 or other library which may providemodules and components that provide the supporting functionality to theTPM.

The ATM 310 may further include a secure API 320 which provides a set offunctions that ATM software 322 may use to configure and communicatewith the TPM through the TSS. In an embodiment of the ATM, the secureAPI may include functions for accessing on-chip cryptographic hardwarefunctions 330 of the TPM such as encryption, decryption hashing, and keygeneration. Examples of on-chip encryption and decryption functions thatmay be accessed through the secure API may include RSA, AES, DES, andTriple DES. In an embodiment of the ATM, the terminal control software324 may perform encryption and decryption operations involved with theperformance of transactions for consumers and servicers using theon-chip functions of the TPM. In alternative embodiments the ATMsoftware may be operative to communicate with the TPM through directaccess to the functions of the TSS. In further alternative embodiments,the ATM software may be operative to communicate with the TPM throughthe cryptography library of the operating system. In a Microsoftoperating system, such a cryptography library may include a Microsoftcryptography API (CAPI), for example.

FIG. 4 shows an embodiment of a TP 400 for an ATM 410 which conforms tothe Microsoft's NGSCB specification. Here the TPM chip 414 maycorrespond to or may be referred to as a security support component(SSC). Also, with this specification the software which interfaces withthe TPM chip may include the NGSCB nexus 420 or other secure kernel orcomponent of an operating system 418. In this described embodiment theTPM may correspond to the TPM 1.2 specification released by the TrustedComputing Group.

An ATM with a NGSCB trusted computing platform may include two modes ofoperation referred to as the standard mode or left hand side 430 and thenexus mode or right hand side 432. Both modes may be operative at thesame time on a computer of the ATM. Legacy applications which are notdesigned for use with a TPM 414 may execute in the standard mode of theplatform. Trusted applications which are designed to use features of theTPM may be granted permission to operate in the nexus mode 432. Suchtrusted applications include the NGSCB nexus 420, nexus computing agents(NCAs), and/or other software components which are adapted to operate inthe nexus mode.

In an embodiment of the ATM 410, at least one of the terminal controlsoftware components 422 of the ATM may be granted permission to operatein the nexus mode. In a TP based on Microsoft's NGSCB specification suchcomponents may be programmed to use features of the TPM throughcommunication with the nexus 420. As used herein, terminal controlsoftware components which interface with a TPM and/or which operate inthe nexus mode are referred to as trusted ATM components 440. In a TPbased on Microsoft's NGSCB such trusted ATM components may correspond toNCAs for example.

FIG. 5 shows an embodiment of a TP 700 for an ATM 710 which conforms tothe Intel LaGrande Technology (LT) specification. Here the TPM 714 maycorrespond to one or more chips integrated with a motherboard of thecomputer of the ATM. In other embodiments, the TPM may be integratedinto the computer processor of the ATM. In this described embodiment theTPM may correspond to the TPM 1.2 specification released by the TrustedComputing Group.

In the LT specification, the software which interfaces with the TPM chipmay correspond to the NGSCB nexus or other secure or protected kernel720 or component of an operating system 718. As with the previouslydescribed NGSCB TP, the LT TP may include two modes of operationreferred to in the LT specification as the standard partition or publicarea 730 and the protected partition or vault 732. Both modes may beoperative at the same time on a computer of the ATM. Legacy applications742 which are not designed for use with the TPM 714 may execute in thestandard partition of the platform. Trusted applications which aredesigned to use the TPM may be granted permission to operate in theprotected partition 732. Such trusted applications may include aprotected kernel 720 such as the NGSCB nexus, and protected applets 721and/or other software components which are adapted to operate in theprotected partition.

In an embodiment of the ATM 710, at least one of the terminal controlsoftware components 722 of the ATM may be granted permission to operatein the protected partition 732. In a TP based on Intel's LTspecification, such components may be programmed to use features of theTP 700 through communication with the protected kernel 720. As usedherein, terminal control software components which operate in theprotected partition defined by the LT specification are also referred toas trusted ATM components 722 and may correspond to protected applets721.

Examples of trusted ATM components which are operative in the nexus modeor protected partition of the TP may include components whichcommunicate financial information such as account data to a remote hostbanking system. Other examples of trusted ATM components may includeservice providers, device drivers, or other portions of the deviceinterface layer of the ATM which communicate with input devices, outputdevices, and transaction function devices such as a cash dispenser, cashrecycler, or depository mechanism. In addition, trusted ATM componentsmay include the terminal applications and/or configuration componentsfor use with servicing, installing, maintaining or configuring the ATM.Further, trusted ATM components may include software for generating auser interface usable by a customer to cause the ATM to performfinancial transactions and functions such as the dispense of cash.

Although, in an ATM which conforms to the NGSCB or LT, all of theterminal control software may be programmed to operate in the nexus modeor protected partition, in other embodiments one or more of the terminalcontrol software components may continue to operate in the standard mode430 (FIG. 4) or standard partition 730 (FIG. 5) of the computer of theATM. For example, legacy ATM software components 442, 742 such as aWOSA/XFS (Windows Open Services Architecture/eXtensions for FinancialServices) manager or other extensions for financial services (XFS) layeror other device interface layer may continue to operate in the standardmode or partition. However, other components, such as softwarecomponents which have access to secure financial information and/oritems of value (i.e. cash and/or deposits) may operate on the nexus modeor protected partition of the TP.

FIG. 6 shows a further embodiment of a TP 600 for an ATM 610 whichconforms to a specification as discussed in the “Trusted Platform ModuleServices in Windows Longhorn” paper issued Apr. 25, 2005 by Microsoftfor a trusted platform as proposed for use with the Microsoft® operatingsystem referred to as “Windows Longhorn” or “Windows Vista”. Here theoperating system may include a TPM driver 604 capable of interfacingwith a TPM chip 602 of the computer 606 of the ATM. The TPM driver 604may be kernel-mode device driver for use with TPM chips that arecompatible with the Trusted Computing Group 1.2 specification or laterdeveloped trusted computing specification. The TPM Base Services 608 maybe a service of the operating system that enables sharing of TPMresources and may be operative to provide a scheduler that coordinatesaccess among application threads using the TPM.

As shown in FIG. 6, components of the operating system operative to usefeatures of the TPM may include a secure startup component 612,administrative tools component(s) 614, and a key storage providercomponent 616. The secure startup component 612 may use the TPM toprotect the integrity of the partition of the computer which stores theoperating system components. The secure startup component maycommunicate with the TPM during the initial boot of the operating systemthrough use of a Trusted Computing Group compliant Basic Input-OutputSystem (BIOS) or an Extensible Firmware Interface (EFI) and the TPMdriver. The secure startup component may decrypt portions of theoperating system and/or verify that portions of the operating systemhave not been altered prior to enabling the portions of the operatingsystem and/or other software components of the ATM to be executed by thecomputer of the ATM. The TPM administration tools components 614 mayinclude user interface tools for common TPM administration functions.The key storage provider component 616 may be used by applications toaccess basic cryptographic functions of the TPM such as the functionsfor generating private keys, signing and other encryption tasks.

The operating system may include a TSS 620. The TSS may correspond to aTrusted Computing Group Software Stack capable of being used by thirdparty application 618 to access features of the TPM. The TSS 620 may besimilar to the TSS 318 discussed preciously with respect to FIG. 3 andconform to the Trusted Computing Group specified architecture forsoftware components that support applications using a TPM. The TSS 620may be adapted to interface with the TPM through the TPM Base Services608 of the operating system. A TSS may also be referred to as a TrustedSoftware Stack.

In embodiments of the ATM, ATM software components may correspond to thethird party applications 618 which access the TPM through communicationwith the TSS. Also rather than or in addition to communicating with theTSS, ATM software components may be adapted to communicate with the Keystorage provider 616 and/or the Administration Tools 614 of theoperating system to access features of the TPM.

In embodiments of the ATM, trusted ATM components may use one or more ofthe following mechanisms of one or more of the previously described TPspecifications: curtained execution, sealed storage, secure I/O, andattestation. With curtained execution, a trusted ATM component isisolated from software that is not trusted by the trusted ATM component.With sealed storage, the trusted ATM component has access to secretinformation stored in the sealed storage in a data store of the ATMwhich is not available to other software unless the other software istrusted by the trusted ATM component. With attestation, the trusted ATMcomponent has access to an authentication mechanism which enables thecomponent to prove its identity to other software components located onthe ATM or remote from the ATM. With secure I/O, the trusted ATMcomponent is operative to receive secure inputs or send secure outputsthrough secure or protected input and output devices of the ATM.

With respect to curtained execution, embodiments of the computerprocessor, associated chipsets 750 of the computer motherboard, TPM,and/or protected kernel of the TP may include protected memorymanagement 750 and protected software execution 752 as defined by the TPspecification of the TP of the ATM. Such protected memory management andprotected software execution may place software processes and other datastored in memory and executing in the processor, in an encrypted,isolated, and/or protected form to prevent unauthorized rogue componentssuch as a virus or worm from acquiring information about softwareprocesses and associated data from the processor and memory of the ATM.

With respect to sealed storage, the TP may be used to manage the storageof secret information in one or more data stores of the ATM. Such sealedstorage may include an internal data store 340 such as a nonvolatile RAMor registers located in the TPM. Such sealed storage may also include adata store 342 which is external to the TPM such as an encrypted file ona hard drive. Information stored in the sealed storage may be encryptedby the TP using public keys and an RSA cryptography algorithm and/orsymmetric keys using a symmetric cryptography algorithm.

Information used by an ATM such as secret keys, signature keys,verification keys, encipherment keys, decipherment keys, private keys,public keys, and authorization keys or other critical information usedin the operation of the ATM may be securely stored in the ATM in thesealed storage through use of the TP. For example, secret keys used byan (EPP) may be stored in an internal or external data store managedthrough use of the TP. Also, private keys used for creating digitalsignatures for the ATM may be securely stored using the TP. The ATM mayuse the TP to sign messages using the private keys stored using the TPM.Examples of other information that may be securely stored in sealedstorage of the ATM using the TP may include transaction information andinformation regulated by government or industry such as anti-fraudmechanism information for areas such as bulk note tables, canistermappings, account access, transaction journals, and repudiation.

In embodiments of the ATM, a trusted ATM component may through use ofthe sealed storage features of the TP cause information to be stored inan encrypted form in a sealed storage in a data store of the ATM using akey associated with the trusted ATM component. Such a trusted ATMcomponent may correspond to the owner of the information. This describedembodiment of the TP may enable the owner-trusted ATM component to usethe TP to retrieve and return the information stored in the sealedstorage back to the owner-trusted ATM component. The owner-trusted ATMcomponent may also selectively grant permission to another trusted ATMcomponent to access through use of the TP the information stored in thesealed storage by the owner-trusted ATM component.

With respect to secure I/O, the TP may be adapted to securelycommunicate with one or more protected input 740 and output devices 744.In embodiments of the ATM, the computer may include a trusted keyboardcontroller or other trusted input device controller adapted for use witha TP. The trusted input device controller may be operative to form atrusted secure communication channel with the one or more protectedinput devices through which communications can be securely transmittedto a trusted ATM component. The secure communications may be encrypted,for example, such that unauthorized software operating on the ATM cannotdetermine the unencrypted form of the information being inputted throughuse of the protected input device. In an embodiment of the ATM, thetrusted ATM components are operative responsive to the securecommunications received from a protected input device to causetransaction function devices to operate. For example, with a protectedtouch screen or keypad input device for example, communications betweena trusted ATM component and the touch screen or keypad may be encryptedsuch that a virus, worm or other unauthorized component operating in thecomputer of the ATM would be unable to acquire private information fromthe touch screen or keypad such as a user's PIN (Personal IdentificationNumber) or other information. Further, with a protected card reader, forexample, communications between a trusted ATM component and the cardreader may be encrypted such that an unauthorized component operating inthe computer of the ATM would be unable to acquire private informationread from a card with the card reader such as an account number.

In addition, one or more of a video graphics controller, receiptprinter, statement printer, passbook printer, or other output device ofthe ATM may correspond to protected output devices 744. For example, theATM may include a protected video graphics controller that is adaptedfor use with a TPM of a TP. Secure communication between the computerprocessor of the ATM and the protected video graphics controller may beencrypted such that a virus, worm or other unauthorized software wouldbe unable to acquire private information sent to the video graphicscontroller or video memory such as the display of account information.Further, the encryption of communications to a video graphics controllermay minimize the opportunity for unauthorized software to cause thedisplay device to output incorrect information or commands. For exampleby encrypting data associated with the formation of a visual userinterface sent to a video graphics controller, an unauthorized softwareapplication may be prevented from prompting a user to input PINinformation at a time when the EPP of the machine is not in a propermode to encrypt the PIN.

In addition to protected input and output devices, other devices of theATM such as transaction function devices 746 may also be adapted for usewith a TP. For example, the TP may be used to establish a securecommunication channel between a trusted ATM component and one or moretransaction function devices such as a cash dispenser. The trusted ATMcomponents and transaction function devices may be operative to send oneor more encrypted messages through the secure communication channelwhich causes the transaction function devices to operate and/or whichcommunicates data between the transaction functions devices and thetrusted ATM components. Examples of such messages may include commandmessages and status messages. In an embodiment of the ATM, a devicecontroller such as a USB controller or other hardware controller of thecomputer of the ATM may be adapted for use with a TP to establish thesecure communication channel between the computer and the transactionfunction devices connected to the controller. Further examples ofestablishing secure connections between a computer in the ATM andhardware devices in the ATM are discussed below.

The TP may be used to perform cryptographic processes such as asymmetricand symmetric encryption and decryption for trusted ATM components. TheTP may also be used to perform key generation, public/private key pairgeneration, random number generation, hash generation, digital signaturegeneration, and digital signature verification for trusted ATMcomponents. In addition, the TP may be used to provide a report orattestation to the current configuration of the ATM or otherinformation. For example, the TP may be used in acquiring and/orverifying information about trusted ATM components and hardware deviceinstalled on the ATM.

With respect to attestation, the information acquired about a componentof the ATM for attestation using the TP is referred to herein as ameasurement of the component. Such a measurement may take place when theATM is initially booted when software initially executes, or at othertimes during the operation of the ATM. The measurements may be securelystored using the TP and used later to determine if the configuration ofthe ATM has changed.

In an embodiment of the ATM, a trusted ATM component and/or an externalsystem remote from the ATM such as a host banking system may beoperative to verify the information about the measured components of theATM. The TP may be used to attest to the information about the measuredcomponent by digitally signing the measurement of the component with aprivate key of the TPM. The digitally signed measurement or hash may besent to the software application, device, and/or external system whichrequested information about the measured component and/or a measuredconfiguration of the machine.

In an embodiment of the ATM, the TPM may include at least one privatekey securely stored in the TPM chip. The TPM may further include atleast one digital certificate that includes the public key whichcorresponds to the private key stored in the TPM. Such a digitalcertificate may be signed by a certificate authority associated with themanufacture of the motherboard, TPM or ATM for example.

The TPM may also be operative to store additional public and privatekeys and corresponding digital certificates. The additional digitalcertificates associated with the TPM may be signed by a certificateauthority which enables them to be verified by authenticating thesignature of the certificate authority. In an embodiment of the ATM, theTPM may be operative to provide a root of trust for the ATM through aPKI infrastructure. The TPM may be operative to extend its trust to oneor more components of the ATM, such as a nexus and trusted ATMcomponents, by building a chain of trust. Also, trusted ATM componentsmay be operative to extend their trust to other components.

In an embodiment of the ATM, the TP of the ATM may be used to enable thecomputer of the ATM to boot into a known state with hardware andsoftware that is verified through use of the TPM. In this describedembodiment, the ATM software 322 such as the terminal control softwaremay include trusted ATM components that are operative to audit theconfiguration of the ATM. Such auditing ATM components may through useof the TP acquire measurements for a plurality of the software and/orhardware components of the ATM. The results of the measurements may becompared to know authorized configurations of valid measurements of thecomponents. In an embodiment of the ATM, such authorized configurationsmay be digitally signed to prevent undetected unauthorized modificationsto the authorized configurations.

In alternative embodiments, the authorized configurations may be storedin a data store managed by a remote system such as a server associatedwith a host banking system. Prior to authorizing the ATM to performtransaction functions or at startup, the host banking system maycommunicate with the ATM to direct that the trusted ATM componentsacquire measurements of one or more devices of the ATM. The measurementsmay be returned to the host banking system for verification against theknown authorized configurations for the ATM. If the measurements do notcorrespond to valid measurements of one or more authorizedconfigurations for the ATM, the host banking system may be operative toprevent the ATM from performing transactions.

In an embodiment of the ATM, the TP may be used to measure components assoon as the ATM is booted. If the hardware and/or software componentsare not successfully verified, the TP may be operatively configured toprevent the computer of the ATM from booting into a fully functionalstate capable of operating transaction function devices. For example,the TPM may be used to verify that the BIOS or EFI of the computermotherboard has not been altered prior to booting an operating system.In addition, the TPM may be used to measure the nexus or other kernel orportion of an operating system, or other software component, beforeenabling the operating system or other software component to execute. Inaddition, the TPM may be used to verify that the one or more of thespecific hardware components (e.g. hard drive, network controller,keyboard, display device) connected to the computer of the ATM have notbeen altered.

In an embodiment of the ATM, a measurement may include loading a portionof the operating system, other software component, or information readfrom a hardware device into secured curtained memory and sending animage of the memory to the TPM chip. The TPM chip may make acryptographic hash of the image. This hash may be permanently andsecurely stored in the TPM chip or elsewhere for use in verifying thatthe operating system, other software components, or hardware components,have not been altered.

On subsequent boots of the ATM and/or execution of portions of theoperating system or other software components, the TPM chip may again beused to measure the portions of the operating system and/or othersoftware components being executed. Before placing the ATM into a fullyfunctional state, the current measurements can be compared to theoriginal or authorized measurements previously stored in the TPM chip orelsewhere to verify that the software configuration of the ATM has notbeen altered. With respect to the Microsoft NGSCB specification, thesoftware being measured and verified using the TPM may include bothtrusted ATM components and other software components and applicationswhich may or may not run on the nexus mode of the TP. In embodiments ofthe ATM, the TP may also be used to measure hardware configurations andhardware devices to verify that the ATM includes the correct hardware.Also, as will be discussed in more detail below, in further embodimentshardware devices in the ATM may be able to use the TP to authenticatesoftware which controls the device prior to permitting the software tocontrol the device. In addition, in embodiments in which a Microsoftoperating system such as Microsoft Vista is loaded on the ATM, thepreviously discussed secure startup component 612 may use a TPM toverify portions of the hardware and/or software of the ATM have not beenaltered and/or to decrypt portions of the operating system or othersoftware components prior to enabling the ATM to boot to a fullyfunctional state.

Although, in the described embodiment, a measurement of a softwarecomponent corresponds to at least one securely stored and/or digitallysigned hash or other cryptographic function of the data which comprisesthe software component, in further embodiments a measurement of asoftware component may correspond to other data acquired from orresponsive to a software component which may be used to authenticate thesoftware component. For example, a software component may be groupedwith other software components either by being located in a commonlocation in a filing system or by being packaged as a group into acommon file. The software components in such groups may be hashed anddigitally signed as a group rather then individually. Therefore inalternative embodiments, a measurement may correspond to data usable toauthenticate groups of software components.

Automated banking machines such as an ATM may be operative to performcryptographic calculations involved with securely sending and receivingan ATM terminal master key, ATM communication keys, and user enteredPINs or other information between the ATM and an ATM host bankingsystem. Examples of ATM systems which use cryptographic calculations andprotocols to securely transfer keys between an EPP of an ATM and a hostbanking system and which may be adapted to use a TP are shown in U.S.application Ser. No. 10/126,140 filed Apr. 19, 2002, which is herebyincorporated herein by reference in its entirety. In an embodiment ofthe ATM, one or more cryptographic calculations required by the EPPdescribed in application Ser. No. 10/126,140 may be performed using theTPM of the TP.

For example, in an embodiment of the ATM, a service technician mayinitiate a function at the ATM or from a remote location which causes atrusted ATM component to send a request to a host banking system for asymmetrical key such as a terminal master key (also referred to as a keyencrypting key) or other key. The request may include a digitalcertificate associated with the TP, TPM, trusted ATM component, and/orEPP. The host banking system may validate the certificate and use thepublic key associated with the certificate to encrypt a terminal masterkey. The host banking system may then send a message to the ATM whichincludes the encrypted symmetrical key. Once the message is received,the trusted ATM component may be used to decrypt the received key usinga corresponding private key and an asymmetric cryptography algorithmsuch as RSA. The message from the host banking system with the receivedkey may be digitally signed by the host banking system. The trusted ATMcomponent may validate the received key through verification of thedigital signature. In this described embodiment, the received key may beused by the ATM to decrypt further symmetrical keys such ascommunication keys (also referred to as a PIN encrypting keys) providedto the ATM by a host banking system. Such a received key or further keysmay be used to encrypt data communicated between the ATM and the hostbanking system such as PINS inputted thorough a keypad of the ATM. In anembodiment of the ATM which includes an EPP, the trusted ATM componentmay securely send the received key such as a terminal master key to anEPP for use by the EPP to decrypt further keys such as a communicationkey provided to the EPP at a later time. The EPP may use the receivedkey or further keys to encrypt PINs inputted into a keypad input deviceof the EPP by a user performing a transaction at the ATM. The encryptedPIN may then be sent to the host banking system for use in authorizingthe transaction to be performed.

In a further alternative embodiment, the received key such as a terminalmaster key may be securely stored by a trusted ATM component in sealedstorage on a data store of the ATM computer rather than sending theterminal master key to an EPP. The trusted ATM component may thenretrieve the terminal master key from sealed storage for use withdecrypting further keys such as communication keys provided to the ATMby the host banking system. The trusted ATM component may then securelytransfer the decrypted communication key to the EPP.

In a further alternative embodiment, after the further key such as acommunication key has been decrypted, the communication key may besecurely stored by the trusted ATM component in sealed storage on a datastore of the ATM rather then sending the communication key to an EPP.The trusted ATM component may then retrieve the communication key storedfrom sealed storage to encrypt PINs inputted into a protected inputdevice other than an EPP prior to sending the PINs to the host bankingsystem for authentication. Such protected input devices may correspondto a keypad, keyboard, touch screen of a display device, or any otherprotected input device of the ATM which conforms to the previouslydescribed secure I/O defined by the TP specification of the TP of theATM. For example, in this described alternative embodiment, a protectedkey pad or touch screen may be operatively configured to securelycommunicate an inputted PIN to the computer and trusted ATM component byestablishing a secure encrypted communication channel between the inputdevice and TP and/or trusted ATM component.

In an embodiment of the ATM, a secure communication channel or a sessionmay be established between a hardware device of the ATM and the computerof the ATM through use of the TPM. The session is created by securelycommunicating a session key between the computer in the ATM and thehardware device in the ATM. Data communicated between the computer andthe hardware device may then be encrypted and decrypted using thesession key. Such data may include operational data sent to or from thehardware device. For example, such operational data may include commandssent to the hardware device which are operative to cause the hardwaredevice to perform a function. Such operational data may also includestatus messages regarding the operation of the hardware device which aresent to the computer.

Both the computer of the ATM and a processor in the hardware device maybe adapted to perform a key transport mechanism protocol which providesunilateral key transport of the session key from the TPM to the hardwaredevice. Such a protocol may correspond to the Key Transport Mechanism 4of ISO.IEC 11770-3. In this described embodiment, the protocol may usean asymmetric encipherment system such as RSAES-OAEP and may use aasymmetric signature system such as RSA with the SHA-1 hash function.The size of the RSA modulus may be 2048 bits, for example. However, itis to be understood that in alternative embodiments, other cryptographicsystems and configurations may be used to carry out the transport of akey between components in the ATM.

FIG. 7 shows an schematic view of the protocol being carried out betweena computer 102 of an ATM 100 with its associated TPM 104 and a hardwaredevice such as an EPP 106 of the ATM. It is to be understood that inthis described embodiment the computer uses the TPM to establish thesecure connection with the EPP. As used herein, the term “using the TPM”corresponds to software operating in the computer which causes thecomputer to access functions of the TPM: for performing cryptographicfunctions on data such as signing data, for retrieving and/or storingdata in a secure manner in the ATM, and/or for performing other TPMoperations.

In this described embodiment, the computer 102 is operative to exchangedigital certificates 110,112, 114 with the EPP 106. After the exchange,the computer has access to at least one public key of the EPP, and theEPP has access to at least one public key of the computer and/or TPM. Inthis described embodiment, the EPP and the computer and/or TPM mayinclude more than one digital certificate, each of which are devoted todifferent operations. For example, the EPP may include a digitalcertificate 112 for use with verifying digital signatures generated bythe EPP and may include a digital certificate 114 for use withencrypting messages being sent to the EPP. However, in alternativeembodiments the EPP and the computer and/or TPM may include only onedigital certificate for use with both encryption and verificationoperations.

In this described embodiment, the processor in the EPP is operative togenerate and communicate a random number 116 to the computer. Inresponse, the computer is operative to use the TPM to generate a message118 which is signed with the private key of the TPM. The messageincludes: the random number of the EPP 116, a further random number 120generated by the computer and/or TPM, a distinguishing identifier 122associated with the EPP, and a key block 124 encrypted by the computerand/or TPM using the public key from the encipherment certificate 114 ofthe EPP. The key block 124 may comprise a distinguishing identifier 126associated with the computer and/or TPM and the session key 128. In thisdescribed embodiments, the distinguishing identifiers for the EPP andcomputer and/or TPM may correspond to serial numbers or other uniquenumbers or names which can be used to identify the EPP and computerand/or TPM. In an embodiment of the ATM, such distinguishing identifiersmay be included in the respective digital certificates 110, 112, and114.

Upon receipt of the message 118, the processor in the EPP may beoperative to: verify the signature of the TPM for the message 130 usingthe public key included in the certificate 110 of the TPM, verify thatthe distinguishing identifier of the EPP 122 matches corresponding datastored in the EPP, and verify the random number of the EPP 116 receivedin the message 118 matches the random number originally sent by the EPP.In response to these verifications, the processor of the EPP isoperative to decrypt the key block 124 included in the message 118 toproduce the session key 128 and the distinguishing identifier 126 of thecomputer and/or TPM. The processor may also verify that thedistinguishing identifier 126 corresponds to the expected identity ofthe computer and/or TPM. Once these verifications have been performed,the processor of the EPP is operative to accept the session key 128 andstore it in a data store of the EPP.

The processor of the EPP is further operative to construct andcommunicate to the computer a further message 132 which is signed by theprocessor of the EPP using a private key associated with the publicverification key included in its verification certificate 112. Thefurther message may include the random numbers 116, 120 and thedistinguishing identifier 126 associated with the computer and/or TPM.

Upon receipt of the further message 132, the computer is operative touse the TPM to verify the signature 134 of the EPP using the publicverification key included in the verification certificate 112 of theEPP. In addition the computer may be operative to verify that the randomnumbers 116, 120 match the random numbers sent in the message 118. Also,the computer may be operative to verify that the distinguishingidentifier 126 matches the corresponding identify information associatedwith the computer and/or TPM. Once these verifications have beenperformed, the computer is operative to begin using the session key 128to encrypt and decrypt information sent to and from the EPP.

The above-described method and system for establishing a securecommunication session between the computer in the ATM and the EPP may beperformed with other hardware devices such as input devices, outputdevices, and other transaction function devices such as a cashdispenser, card reader, and depository.

With respect to the EPP, all inputs provided through operation of thekeypad of the EPP may be encrypted with the session key and communicatedto the computer for use with carrying out transactions with the ATM.Such encrypted inputs may include individual key strokes of the numberedkeys of the keypad which may correspond to an amount of value todispense, an amount of value to deposit, an amount of value to transfer,or other numerical information needed to perform transaction functionswith the ATM. In addition, such encrypted inputs may correspond toindividual key strokes of non-numeric keys (e.g. “cancel” and “enter”keys) of the keypad. Also, encrypted inputs corresponding to numerickeys, and/or non-numeric keys may be used to control or select one of aplurality of menu options of a user interface displayed through adisplay device of the ATM. The selection of such menu options may causethe ATM to progress through the steps involved with carrying out atransaction function (e.g. dispensing cash) or other operations such asservicing the machine.

In embodiments of the ATM, software operating in the EPP may beoperative to send operational messages such as command messagesencrypted with the session key to the EPP, which messages cause the EPPto perform an operation. For example, the EPP may be responsive to anencrypted command message sent from the computer to place the EPP in asecure mode for entering a PIN. In this secure mode, the EPP may store asequence of key presses which correspond to the input of a PIN. For eachkey stroke the EPP may send an encrypted message to the computer of theATM which notifies the ATM that a key has been pressed but does notinclude the actual value of the key being pressed. Software operating inthe computer of the ATM may be responsive to these messages to display astar or asterisks symbol through a display device of the ATM whichcorresponds to each input into the EPP.

Upon entry of the PIN, the user may provide an input through a functionkey, a touch screen or an ENTER key on the keypad of the EPP whichcauses the computer to send a further command message to the EPP whichplaces the EPP out of the secure mode. Upon receipt of this furthercommand message, the EPP may encrypt the stored PIN with a symmetricalkey such as a communication key and send the encrypted PIN key to thecomputer in a message encrypted with the session key. The computer mayuse the TPM to decrypt the message using the session key. The resultingencrypted PIN may then be communicated to a host banking system. Thehost banking system also has access to the communication key and isoperative to decrypt the PIN for use with authorizing a transactionbeing performed with the ATM such as a cash dispensing transaction.

In embodiments of an ATM which include a TPM, the TPM may be used toestablish an encrypted communication session with a remote server suchas a host banking system. Such an encrypted communication session may beformed by carrying out a secure sockets layer (SSL) protocol, atransport layer security (TLS) protocol, a virtual private network (VPN)protocol or any other protocol which may use client side (e.g. ATM) sideauthentication. Examples of ATMs which use SSL to communicate withremote servers are shown in U.S. application Ser. No. 10/990,334 filedNov. 16, 2004, which is hereby incorporated herein by reference. In thisdescribed embodiment, the computer in the ATM may use the TPM tosecurely store a key in an encrypted form either in the TPM or in anencrypted file stored elsewhere in the ATM. For an SSL or TLS protocol,the key stored using the TPM may include a private RSA key or otherasymmetric key. The ATM may include a software component capable ofcausing the TPM to generate the private key and a corresponding publickey for use with the asymmetric algorithm performed during the SSL orTLS protocol. The software may further cause a certificate requestmessage to be generated and sent to a remote certificate authority foruse in generating a digital certificate which includes the public key ofthe ATM. The software may be capable of receiving the digitalcertificate and storing it in the ATM for later use during the SSL orTLS protocol.

When a SSL or TLS connection is being formed by the at least onecomputer in the ATM with a remote server, software operating in thecomputer of the ATM may forward the digital certificate of the ATM tothe remote server. The software may also access the TPM to cause datainvolved with establishing the SSL or TLS connection to be encryptedusing the private key of the ATM. In this described embodiment, thesoftware used for establishing the SSL or TLS connection may include abrowser that is adapted to retrieve the private key using the TPM of theATM. For an embodiment which establishes a VPN, a VPN client softwareapplication may be used which is adapted to retrieve the private keyfrom the TPM of the ATM.

In a further embodiment of an ATM, the TPM may be used to establish anencrypted communication session between the computer of the ATM andhardware devices of the ATM using the SSL or TLS protocols. In thisdescribed embodiment, the hardware devices may be operative to use anetwork protocol such as TC/IP to communicate with the computer of theATM. The physical connection between the devices and the ATM may includea USB connection, ethernet connection, or any other physical connectionthat is operative to permit network communication such as TCP/IP.Examples of ATMs which include an internal network for connecting ATMdevices to a computer in the ATM are shown in U.S. application Ser. No.09/505,594 filed Feb. 16, 2000, which is hereby incorporated herein byreference. In this described embodiment, the ATM devices may includerespective client side digital certificates for use with establishing anSSL or TLS connection with the computer of the ATM.

As discussed previously, in an embodiment of an ATM, the TPM may be usedto measure and verify that hardware devices and/or software of the ATMhave not been altered, prior to enabling the ATM to perform transactionfunctions using the hardware devices and software. For example, the TPMmay be used to measure and verify that valid transaction functiondevices are installed and/or have not been altered in the ATM, such as acash dispenser and depository mechanism. The TPM may also be used tomeasure and verify that other types of hardware devices of the ATM arevalid and/or have not been altered such a card reader device, displayscreen, function keys, keypads, network card, hard drives, CD readers,DVD readers or any other device that may be included in an ATM. Inaddition or alternatively, the TPM may be used to measure and verifysoftware components used to control the hardware devices of the ATM havenot been altered. Examples of such software devices which may bemeasured and verified using the TPM may include operating system files,device drivers, configuration files, service providers, databases, XFSlayers, ODS layers, TEC components, browser software, JVMs, terminalcontrol software components, diagnostic software applications, serverapplications, service and maintenance software applications or any othersoftware components including software files and data that may beincluded in an ATM. In addition, the TPM may be used to measure andverify that the BIOS or EFI of the computer of the ATM has not beenaltered.

In an embodiment of an ATM, devices in the ATM such as transactionfunction devices may be adapted to authenticate the particular softwarestack which controls and/or receives data from the devices. For example,a cash dispenser may be adapted to challenge the integrity of theoperating system state prior to dispensing cash in response to commandsreceived from the software stack which controls the cash dispenser. Onlywhen approved software is confirmed as executing in the computer of theATM will the device operate in response to commands from the softwareand/or will send operational data to the software. In this embodiment,the TPM is used to measure the current software stack. The currentmeasurements are sent to the device which issued the challenge. Aprocessor in the device may then compare the current measurements toapproved reference measurements of the software stack previously storedin the device before allowing the device to operate.

The following is a description of an embodiment of the ATM in which thecash dispenser is adapted to verify a software stack associated withoperating the cash dispenser. However, it is to be understood that inalternative embodiments other transaction functions devices in the ATMsuch as a card reader, depositor, EPP, and other devices including inputand output devices of the ATM may be adapted to very software associatedwith the device.

In this described embodiment, the ATM may include authenticationsoftware operating in the computer of the ATM which is operative toenable a user to select which software components comprise a softwarestack to be validated by the cash dispenser. The software componentsthat may be selected, for example, may include device drivers, serviceproviders, module interfaces, XFS software, application libraries,terminal control software, diagnostic software, or any other softwareoperative to control the operation of or communicate with the cashdispenser. In this described embodiment, these software components maybe adapted to be locked so as to limit access to themselves to onlyother components that comprise the selected software stack. As a result,when the device driver is locked, the device driver will only enable oneof the other software components in the selected stack to access devicedriver functions of the device driver and will not permit softwarecomponents not included in the stack (e.g. a virus) to access the devicedriver functions.

In an embodiment of the ATM, the authentication software may cause theTPM to generate reference measurements for each of the selectedcomponents which comprise the software stack upon execution of thecomponents by the computer of the ATM. Each reference measurement mayinclude a hash (e.g. digest) of the software component which isdigitally signed using the TPM. The authentication software may thensend the generated reference measurements to the cash dispenser forstorage therein.

In an embodiment of the ATM, the authentication software may only beoperative to update the cash dispenser with a set of referencemeasurements at times when the operator performing the configuration ofthe ATM is verified as having sufficient permissions to do so. Such averification may be performed by adapting the software and/or the cashdispenser to only permit updating of the reference measurements when thedoor of the chest of the ATM is open. In an embodiment of the ATM,inside the chest, the ATM may include an input device such as a switchor button which when actuated by the user is operative to cause and/orpermit the software to update the cash dispenser with updated referencemeasurements of the selected software stack.

FIG. 8 shows a schematic view of an ATM 500 which includes a computer502, in operative connection with a transaction function device whichcorresponds to a cash dispenser 504. Here the cash dispenser is locatedinside a chest or safe 512. The described button or switch 520 is alsolocated inside the chest 512. In this described embodiment the computerincludes at least one processor 514, a TPM 515, and a hard drive 510, orother storage device operative to store a plurality of softwarecomponents 506 including the selected software stack 522 associated withthe cash dispenser and the described authorization software adapted toenable the cash dispenser to verify the software stack. The cashdispenser includes a processor 516, firmware 526, a data store such as anonvolatile memory device 518, and associated cash dispenser hardware522 for storing and dispensing cash.

In an embodiment of the ATM, the input device 520 may be in operativeconnection with the cash dispenser, and when manipulated by a user maybe operative to place the cash dispenser in a mode that is operative toaccept new approved reference measurements 540 sent by theauthentication software application 524. Acceptance of the referencemeasurements may include storing the reference measurements in thememory device 518 and deleting any previously approved referencemeasurements therefrom. The authentication software may also send thecash dispenser a digital certificate associated with the TPM. In thisdescribed embodiment, the cash dispenser may be manufactured to includethe digital certificate of the certificate authority which signed thedigital certificate of the TPM so that the processor of the cashdispenser is operative to authenticate the digital certificate of theTPM.

Each time the cash dispenser software stack 522 is initially started inthe computer of the ATM, the TPM may be used to measure the softwarewhich comprises the stack 522. Such measurements may be stored in theplatform configuration registers within the TPM or in an encrypted fileon the hard drive thorough operation of the TPM.

As part of a cash dispenser initialization routine, the cash dispensermay be operative to send a challenge message 542 to the computer todetermine if the approved software stack is running in the computer. Thechallenge message may include a random number generated by the processor516 in the cash dispenser. In this described embodiment, a cashdispenser device driver or other software operating in the computer 502may be responsive to the challenge message to cause the TPM to appendthe random number to each of the current measurements of the softwarestack and to digitally sign the combination of each measurement andrandom number with the private key of the TPM. Each digitally signedmeasurement/random number 546 may then be returned by the device driveror other software to the cash dispenser 504.

The processor 516 of the cash dispenser may verify the digitalsignatures of the current measurements using the public key from thedigital certificate of the TPM. In addition, the processor 516 of thecash dispenser may verify that the random number included with eachcurrent measurement matches the random number sent in the challengemessage 542. In addition, the processor 516 of the cash dispenser maycompare the current measurement hash values to the approved referencehash values stored previously in the data store of the cash dispenser.If the measurements match, the cash dispenser is placed in a mode whichallows dispensing. If the values do not match, the processor isoperative to send a fault message to the computer indicative of thecurrent software stack not matching an approved software stack foroperating the cash dispenser.

In the described embodiment, each time software included in the cashdispenser software stack is upgraded or otherwise modified, theauthentication software may be operated by a user to update the approvedreference measurements stored in the cash dispenser. Such approvedreference measurements may be acquired by the authentication software byusing measurements of the software as generated using the TPM. However,in an alternative embodiment, the approved reference measurements may begenerated remotely from the ATM and sent to the ATM for storage in thecash dispenser.

The installation routine for installing the updated software may includeusing the authentication software previously described to transfer theremotely generated approved reference measurements for the softwarecomponents to the cash dispenser from a remote server However, in afurther embodiment, the remotely generated approved referencemeasurements may be included with the installation software or packagesassociated with the software components. When the installation softwareis used to install the software components on the ATM, the installationsoftware may also install the remotely generated approved referencemeasurements for the software components in the ATM.

After the input device 520 within the chest has been operated by a user,the authentication software may then send the remotely generatedapproved reference measurements to the cash dispenser for storagetherein. The cash dispenser may have been manufactured or otherwiseconfigured to include in the data store 518 the public key of the entitywhich signed the approved reference measurements. The processor in thecash dispenser may then use the public key to verify the signatures ofthe approved reference measurements prior to enabling the cash dispenserto use the approved reference measurements to authenticate cashdispensing software components.

Embodiments of an ATM may include a mechanism for authenticating usersoperative to service the ATM through use of a portable storage deviceplaced in operative communication with the ATM. Such a mechanism may beadapted for use with both ATMs which include a TPM and ATMs which do notinclude a TPM. As shown in FIG. 2, the ATM may include a communicationdevice 60 which is operative to communicate with a portable storagedevice 62 of a user. Such a communication device 60 may comprise ahardware port such as a USB port adapted to communicate with a portablestorage device 62 such as a portable USB device. In alternativeembodiments, the communication device of the ATM may correspond to awireless communication transmitter/receiver (e.g. Bluetooth®, IR, IEEE802.11) adapted to communicate wirelessly with a portable storage deviceplaced within several feet of the ATM.

In this described embodiment, the computer of the ATM includes anoperating system with at least one login account. The login account maycorrespond to an administrative account or other account which hassufficient permission to execute software components operative toconfigure and/or service the ATM. The login account requires an accountpassword to successfully log into the account. In this describedembodiment, the account password may be different for each ATM in whichthis described authentication mechanism is employed.

The portable storage device may include stored therein an encryptedfirst portion of the account password. The ATM may include a loginsoftware component operative in the computer of the ATM which isoperative to cause the computer to produce a decrypted first portion ofthe account password through communication with the portable storagedevice. The login software component may further cause the computer toaccess a second portion of the account password from a data store in theATM. Such a data store may correspond to the operating system registryor some other data store located in the machine.

The login software component is operative to cause the computer togenerate the full account password responsive to the first portion andthe second portion and is operative to cause the computer to log intothe login account of the operating system using the generated accountpassword.

For a USB device or other portable storage device which requires aphysical connection with a communication port of the ATM, the loginsoftware component may be operative to perform one or more of thesedescribed functions upon detection of the portable storage device beingplaced in the port. For example, upon detection of the portable storagedevice being connected to the port, an event or function of the loginsoftware may be triggered which causes the login software to output aprompt through an output device for the user to enter his/her PINassociated with the portable storage device. In addition, the loginsoftware component may be operative to automatically log out the loginaccount responsive to the detection of the portable storage device beingremoved from the port.

In an ATM which includes a TPM, the portable storage device maycorrespond to a flash memory device such as a SanDisk® 128 Megabyteflash drive or other USB nonvolatile memory storage device. After theservice user inserts the flash drive into the communication port of thecomputer of the ATM, the login software component may be adapted toprompt the user to enter through an input device of the ATM a passwordsuch as a PIN which is associated with the flash drive. As shown in FIG.9, the login software component 204 may also be operative to retrieve acredential 202 stored on the flash drive 200. In an embodiment of theATM, the operating system may be adapted to automatically mount theflash drive in association with a file system drive letter or directory.The login software component may be operative to retrieve the credentialby accessing the drive letter or directory corresponding to the newlymounted flash drive.

In this described embodiment, the credential may include identity dataassociated with the user and/or the flash drive which is appended to ahash of the PIN which is associated with the flash drive. The credentialmay be digitally signed by a certificate authority trusted by the ATM.The login software component is operative to verify the signature on thecredential using a public key associated with the certificate authoritywhich signed the credential 202. In an embodiment of the ATM, thedigital certificate of the certificate authority which includes thepublic key may be stored in a data store of the ATM.

In this described embodiment, the login software component is operativeto calculate a hash of the inputted PIN and compare this calculated hashto the hash of the PIN included in the credential. Responsive to thehashes being confirmed as matching, the login software may automaticallylog the user into the login account of the ATM or may present the userwith a selectable menu option which when selected by the user using aninput device of the ATM is operative to cause the login device to loginto the login account.

In this described embodiment, the flash drive may further include storedtherein an encrypted first portion of the account password. As shown inFIG. 9, the login software component may be operative to retrieve theencrypted first portion 206 of the account password from the flash driveand use the PIN and the TPM to decrypt it. To accomplish the decryption,the login software component may be operative to generate a symmetricalkey from the PIN. The generated symmetrical key may be used by the loginsoftware component to decrypt the encrypted first portion of the accountpassword to produce an intermediately encrypted first portion of theaccount password. Next the login software may be operative to use theTPM to decrypt the intermediately encrypted first portion of the accountpassword to produce the decrypted first portion of the account password.In this embodiment, the TPM may be operative to access a furthersymmetrical key stored using the TPM which is used by the TPM and/or thelogin software to decrypt the intermediately encrypted first portion ofthe account.

As discussed previously, the login software is operative to retrieve thesecond portion of the account password from a data store of the ATM suchas a registry of the operating system. The login software may thencombine the fully decrypted first portion of the account password withthe second portion of the account password to produce a password capableof being used to log into the login account.

The identical first portion of the account password may be used withrespect to a plurality of ATMs. However, the second portion of theaccount password may be randomly generated for each ATM. As a result,the combination of the first portion and the second portion will producea unique password for logging into the login account of each respectiveATM.

The previously described portable storage device (e.g. USB flash drive)may be used to log into an ATM which includes a TPM. However, in analternative embodiment, a portable storage device which includes aprocessor and an encrypted data store may be used to log into an ATMwhich does not include a TPM. Such a device may correspond to a USBcryptographic token device which only permits access to its encrypteddata responsive to the processor on the device receiving a properpassword or PIN from the ATM or otherwise authenticates the ATM.

In this alternative embodiment, the data stored in the encrypted storagemay include the first portion of the ATM account password. Rather thanusing the inputted PIN to form a symmetrical key used to decrypt thefirst portion of the account password as described previously, the loginsoftware component may communicate the PIN to the cryptographic tokendevice. As shown in FIG. 10, the processor of the cryptographic tokendevice 220 may authenticate the PIN and forward a digital certificate222 associated with the cryptographic token device to the login softwarecomponent 224. The login software component may verify the digitalcertificate using a public key associated with the trusted certificateauthority which signed the certificate of the cryptographic tokendevice.

Once the certificate of the cryptographic token device has beenauthenticated, the login software component may generate and send arandom number 226 to the cryptographic token device. In response, theprocessor of cryptographic token device may sign the received randomnumber with a private key and send the signed random number 228 to thelogin software component.

The login software component may be operative to verify the signature ofthe random number using the public key from the certificate of thecryptographic token device. The login software may further be operativeto verify that the random number signed by the cryptographic tokendevice matches the random number sent by the login software component.

Once the signed random number is authenticated, the login software mayautomatically begin the process of logging into the login account or mayprompt the user to select a menu option before proceeding to log intothe login account. The process of logging into the login account mayinclude the login software component causing the processor of thecryptographic token device to decrypt the first portion of the accountpassword and forward the first portion of the account password 230 tothe login software application. The login software application may thencombine the first portion retrieved from the cryptographic token devicewith the second portion of the account password stored in the machine toproduce the full account password. The full account password may then beused by the login software application to log into the login account.

In these described embodiments of either the flash drive or thecryptographic token, when the ATM is being manufactured, serviced, orotherwise configured to have the login account operative to service theATM, the account password may be initially set for the account passwordthrough use of the portable storage device. For example, the loginsoftware component or another software component may be operative torandomly generate the second portion of the account password and storethe second portion in a data store of the ATM such as the registry of aMicrosoft® operating system. In addition, the login software may acquirethe first portion of the account password from a portable storage deviceas discussed previously and concatenate or otherwise combine it with therandomly generated second portion of the account password. The loginsoftware may then create an administrative or other type of account withsufficient permission to service the ATM and set the password for theaccount to the full account password generated from the first and secondportions of the account password.

In this described embodiment, the login software component or anothersoftware component operative to generate the ATM account password, maybe used to change the password for the login account as well. This maybe accomplished by a user selecting a menu option of the computer whichis operative to cause the login software component to generate the ATMaccount password as discussed above using a newly generated randomsecond portion of the account password. The login account may then beupdated to have the newly generated account password.

In a further embodiment, the login software may be operative to updatethe password automatically each time a user logs into the ATM. Forexample, when a user inserts his/her portable storage device, entershis/her PIN, and logs into the login account using the login softwarecomponent, the login software component may be further operative to:generate a new second portion of the account password, save the secondportion in the data store of the ATM, combine the first portion of theaccount password retrieved from the portable storage device with thenewly generated second portion to form a new account password, andupdate the login account to have the new account password.

As described previously, the credential stored on the flash drive mayinclude identity information. Also, the digital certificate of thecartographic token device may also include identity information. Suchidentity information may be uniquely associated with the device and orthe user which has been issued the portable storage device. The ATM mayinclude at least one listing of identity information for credentialsand/or certificates stored in a data store of the ATM. The at least onelisting may correspond to a list of authorized credentials/certificates(“white list”) and/or a list of revoked credentials/certificates (“blacklist”). The ATM may be responsive to a listing of authorizedcredentials/certificates to only permit portable storage devices withcredentials/certificates corresponding to identity information includein the listing to have authorization to log into the ATM using the loginsoftware component. Portable storage devices which do not havecredentials/certificates with identity data in the listing will not bepermitted by the login software component to log into the ATM. In thesame embodiment or in an alternative embodiment the ATM may beresponsive to a listing of revoked credentials/certificates to preventportable storage devices with credentials/certificates that haveidentity information in the listing to have authorization to log intothe ATM using the login software component.

In these described embodiments, the listing(s) of authorized and/orrevoked credentials/certificates may be updated at each ATM remotely bydownloading the listing(s) from a remote server. In further embodimentsthe listing(s) of authorized and/or revoked credentials/certificates maybe stored on a portable storage device of an authorized user. When sucha portable storage device is used to successfully login into an ATM acopy of the listing(s) may be copied to the ATM for storage therein. Thelisting(s) may be digitally signed by a certificate authority trusted bythe ATM. Such a certificate authority may be the same certificateauthority which signed the credential/certificate. The ATM may beoperative to authenticate the digital signature on the listing(s) priorto accepting the listing for use with authorizing or permitting portablestorage devices to be used to log into the ATM.

In embodiments where the ATM includes legacy components which mayoperate in the standard mode or standard partition and/or were notdesigned for use with a TPM, the TP may be used to minimize the securityrisks such legacy components may pose to the ATM. For example, ATMs mayinclude an XFS layer which by itself may have limited functionality forsecurely controlling devices of the ATM. A TP may be used to measure andverify both the XFS layer and components that receive and sendcommunications through an XFS layer of an ATM. Examples of an ATM systemwhich is operative to establish secure communications between componentsof an XFS enabled ATM and which may be adapted to use a TP to establishsuch secure communications are shown in U.S. application Ser. No.10/722,065 filed Nov. 24, 2003, which is incorporated herein byreference in its entirety.

For example, XFS enabled ATMs may include application layer components.Such application layer components may be operative to control XFScompatible hardware devices through communication with an XFS layer. Inthis described embodiment the application layer components above the XFSlayer may correspond to trusted ATM components. In addition, one or moreof the device driver layer components or other software interfacesbetween the XFS layer and the hardware components may also be trustedATM components. Examples of device driver layer components includedevice drivers, XFS service providers, and module interfaces such asunified base release (UBR) components or the Diebold Agilis moduleinterface (AMI).

In an embodiment of the ATM, to make communications with the XFS layermore secure, the device driver layer components may only be responsiveto control hardware devices when the communication received from the XFSlayer has been confirmed to originate from a trusted ATM component. Inthis embodiment, a security component of the ATM may be operative tosupply this confirmation to the device driver layer components. Forexample, each time an application layer component communicates throughthe XFS layer, the application layer component may also notify thesecurity manager component. The security manager component may thenconfirm to a device driver layer component that the communicationreceived through the XFS layer originated from an authorized trusted ATMcomponent. In this described embodiment, the application layercomponents, device driver layer components, and the security manager mayuse the attestation features of the TP to prove their identities to eachother and to establish secure communication between them.

For example, a first application layer component may send a firstcommunication to a security manager component of the ATM. The firstcommunication may be attested to through use of the TP to enable thesecurity manager component to authenticate the first communication. Theapplication layer component may then send a second communication throughthe XFS layer of the ATM which is directed to the device driver layer ofthe ATM. In this described embodiment, the device driver layer may causea hardware device of the ATM to operate responsive to both the secondcommunication and the security manager.

In this described embodiment, the device driver layer may communicatewith the security manager to verify that it may operate the hardwaredevice responsive to the second communication. The communications fromthe security manager may be attested to through use of the TP to enablethe device driver layer component to authenticate communications fromthe security manager.

In addition to using the TP to authenticate communications passedthrough an XFS layer or other software stack of the ATM, the TP may alsobe used to measure and verify that the software stack that correspondsto the components of the XFS layer, application layer and device driverlayer or other software stack of the ATM are valid and have not beenchanged to an unauthorized configuration.

The ATM may include service software operative to manage changes to theTP and the trusted ATM applications. The service software may modify theauthorized states of the ATM that are measured and/or verified by theTP. The service software may enable different portions of the ATM to beconfigured based on the type of user performing the task. For example,an administrative user may be permitted to update the TP to trust newhardware and/or software installed on the ATM, while a maintenance usermay be limited to updating a specific subset of the software and/orhardware configurations to be trusted by the TP. In embodiments of theATM, the TP may also be used to maintain an audit trail of all changesto the configuration of the ATM. Audit trail logs for operations of theTP and hardware and software components of the ATM may be securelystored in sealed storage on a data store of the ATM.

In embodiments of the ATM, the service software may be operative tospecify which SPs, device drivers, application or other ATM componentsare trusted and enabled to operate in the nexus mode or protectedpartition of the ATM TP as trusted ATM components. The ATM may include auser interface which enables an authorized user to grant individually oras a group, potential trusted ATM components permission to operate usingthe TP. Each trusted ATM component may include a manifest which includesa hash of the code of the program(s) or a public key(s) usable to verifydigital signatures of the code of the program(s). The TP may beoperative to authenticate each trusted ATM component using theinformation in the manifest. The manifest in turn may include a digitalsignature which can be authenticated by the TP to enable the trusted ATMcomponent to operate in the ATM.

In addition to including software which specifies which applicationsinstalled on the ATM are trusted by and/or are granted permission to usethe TP of the ATM, the ATM may include configuration applications whichare operative to update the ATM with new authorized softwareconfigurations of the ATM responsive to a license or other accessed orinputted set of rules. Examples of an ATM platform which is operative toauthorize the installation and/or configuration of software on the ATMand which may be adapted to use a TP to authenticate an installationand/or configuration of an ATM are shown in U.S. application Ser. Nos.10/732,204 filed Dec. 9, 2003 and 09/957,982 filed Sep. 21, 2001, whichare incorporated herein by reference in their entirety. In embodimentsof the ATM, license information for software being installed on an ATMmay be securely stored in sealed storage in a data store of the ATM.

Examples of license information which may be securely stored in sealedstorage may include: configuration rules for software applications andhardware devices of the ATM, software application expiration dates, thename of the customer, or entity licensing the software, serial numbersfor the software application, version numbers for the softwareapplications, authorization keys for the software applications, softwareIDs, hardware IDs, or any other information which is associated with theATM. Each time an ATM is booted and/or an application of the ATM isstarted in the ATM, the license information may be retrieved from sealedstorage and compared to the state of the ATM as measured using the TP ofthe ATM. If the current measured state of the ATM does not correspond tothe license information, the TP and/or ATM software may be operative toprevent the ATM from booting, and/or prevent the ATM software fromrunning in an enabled state.

The process of installing the new software may include granting any newor updated trusted ATM components with permission to use and/or betrusted by the TP. For example, trusted ATM components may be grantedpermission to operate in the nexus mode or protected partition of theATM TP. Also the TP may be updated to include authorized measurementsfor the newly installed software.

The TPM may include a digital certificate signed by the manufacture orsupplier of the TPM or computer motherboard. The TP may also be used toacquire additional digital certificates for the ATM. Such additionalcertificates may be issued or signed by a specific certificate authoritythat is trusted by one or more trusted ATM components of the ATM. In anembodiment of the ATM, the trusted ATM components may require the ATM tobe issued one or more digital certificates from the specific certificateauthority prior to becoming fully functional on the ATM. In addition,systems remote from the ATM such as a host banking system, financialtransaction server, or other server, may also require the ATM to beissued one or more digital certificates from a specific certificateauthority prior to performing functions with the ATM.

For example, a trusted ATM component of the ATM may include a devicedriver such as a service provider (SP) or other component which controlsthe operation of a cash dispenser. Such a cash dispenser device drivermay only be operative to cause the cash dispenser to dispense cash,after the cash dispenser device driver has verified that the TP haspossession of a particular private key. Such a private key maycorresponds to a public key named in a digital certificate issued by aspecific certificate authority that is trusted by the cash dispenserdevice driver. In an embodiment of the ATM, communications received bythe cash dispenser device driver may be digitally signed or attested toby the TP using the private key. If the public key associated with thedigital certificate issued by the specific certificate authority isusable to verify the digitally signed or attested to communication, thenthe cash dispenser device driver may become operative to operate thecash dispenser in the ATM.

Although in this example a device driver has been described as beingoperative to authenticate the TP, it is to be understood that in otherembodiments of the ATM other trusted ATM components may be operative tomake this verification before enabling device drivers to operatehardware devices. For example, in addition to service providers, thedevice driver layer of the ATM may include a module interface layer suchas a UBR or an AMI which provides an additional layer of abstractionbetween the service providers and the hardware devices. One or more ofthe service providers may be programmed to control hardware devicesthrough communication with the module interface components rather thandirectly communicating with one or more hardware devices. In thisdescribed embodiment, the module interface may be adapted toauthenticate the TP before enabling one or more SPs to operate theirrespective hardware devices.

In further embodiments, the hardware devices themselves may only permita function to be performed after the hardware device has verified thatthe TP has possession of a particular private key. Such a private keymay correspond to a public key named in a digital certificate issued bya specific certificate authority that is trusted by the hardware device.Such a public key may be stored in the hardware device. In thisdescribed embodiment, communications received by the hardware device maybe digitally signed or attested to by the TP and/or a device driver orother ATM component using the private key. A processor in the hardwaredevice may then authenticate the digital signature associated withcommunication using the public key. If the hardware device is able toverify the digitally signed or attested to communication, then thehardware device may become operative to perform a function in responseto the communication.

In an embodiment of the ATM, service software operating in the computerof the ATM may be operative to install and manage digital certificatesused in the operation of the TP. Examples of digital certificates thatmay be managed on the ATM by the service software for one or more of thepreviously described TP specifications may include: validationcertificate, TPM endorsement certificate, TPM identity certificate,conformance certificate, and/or platform certificate. The validationcertificate may include data that includes TPM validation datastatements and labeling. The endorsement certificate may be used tovouch for the existence of a particular TPM. The TPM identitycertificate may include a public key for a TPM identity and adescription of the TPM and/or TP. The conformance certificate may beissued by an entity chosen by the manufacture of the TP to vouch for theplatform meeting the requirements of the specification for the ATM. Aplatform certificate may attest that the ATM TP platform has been builtaccording to the manufacture of the ATM.

In embodiments of the ATM, service software installed on the ATM mayinclude ownership management functions for managing a transition inownership of the ATM: from the manufacture of the ATM to the entityresponsible for installation of the ATM, to the institution or entitythat operates the ATM, and to the entity that is responsible formaintenance of the ATM. The service software may be operative to managein a trusted manner the identities and status settings for the TP as theATM transitions from one entity to another.

The service software of the ATM may also be operative to perform securebackup and recovery functions of information stored on the TPM chipand/or encrypted files stored in the protected partition or in othersealed storage managed by the TP. Such backups of information managed bythe TP may also be securely stored on a system remote from the ATM in anencrypted form which can not be deciphered by the remote system. Theservice software of the ATM may also be operative to securely migrateselected information managed by a TP of an ATM to a TP of a trustedplatform to support maintenance of the ATM.

In embodiments where the cryptographic functions on the TPM chip are notsufficient for the cryptography requirements of the ATM, the TP may beoperative to securely manage cryptographic calculations using protectedcryptographic software and/or hardware components 332 which are externalto the TPM. Such external cryptographic components 322 may includecryptography calculations performed by the CPU(s) of the computer of theATM responsive to the TPM, nexus, TSS, a cryptography API of theoperating system, and/or a trusted ATM component.

ATMs may be manufactured using a motherboard in which ownership of theTPM has not yet been established. Either during or after themanufacturing of the ATM, ownership of the TPM may be established byinstalling and executing service software including TPM configurationsoftware associated with the TPM on a hard drive of the ATM. In oneexemplary embodiment, the TPM configuration software may include a TPMdriver, a Trusted Software Stack (TSS), cryptography service providersoftware, and/or any other TPM software operative to configure a TPM andacquire certificates associated with RSA keys generated and/or storedusing a TPM. In an exemplary embodiment the hard drive of the ATM may bepartitioned to have at least two partitions. The TPM configurationsoftware may be installed on one of the partitions and the ATMapplications that run during normal ATM operation for a customer may beinstalled on a second one of the partitions. In one embodiment, afterthe TPM configuration software has been used to configure the TPM, theTPM configuration software may be deleted from the first partition orotherwise removed from the hard drive of the ATM.

For a TPM 1.2 compliant TPM, the TPM configuration software may beoperative to take ownership of the ATM by establishing a password forthe TPM. During the process of establishing ownership of the TPM, theTPM may produce a number of RSA public and private keys includingStorage Root Keys and Endorsement keys. The TPM configuration softwaremay also be operative to cause the TPM to generate further RSA keys suchas signature keys.

The TPM configuration software may facilitate generating certificaterequest messages (e.g. PKCS#10 certificate request) including forexample the signature public keys generated using the TPM. The TPMconfiguration software may also facilitate communicating the certificaterequest messages to a Certificate Authority through a network inoperative connection with the ATM. The TPM configuration software mayalso facilitate receiving the requested certificates from theCertificate Authority and storing the received certificates in the ATMsuch as on the second hard drive partition.

In an exemplary embodiment, the signature private key may be used by theTPM to sign data (e.g. the message (118) shown in FIG. 7) usable toestablish secure communications between a computer in the ATM and ahardware device connected to the computer of the ATM such as an EPP,cash dispenser or other device. Also, as described previously, thecorresponding certificates may be communicated to the hardware devicesfor use by processors in the hardware devices to authenticate thedigital signatures generated using the TPM.

The TPM configuration software may also be used to securely forward dataassociated with the configuration of the TPM to a remote backup databasefor later use in recovering the ATM after a hard drive failure or otherevent which destroys data stored on the ATM usable to interface with theTPM. Such backup data may include certificates, keys, and/or the ownerpassword associated with the TPM.

For ATMs that may not be connected to a network in operative connectionwith a Certificate Authority or a backup database, the TPM configurationsoftware may be operative to store and/or retrieve certificate requestmessages, returned certificates, and/or TPM backup data on/from portablestorage devices (e.g. USB drives, CDs, DVDs) accessible by a technicianoperating the TPM configuration software. The technician may then movethe portable storage device between the ATM and a further computerconnected to a certificate authority or backup database through anetwork to facilitate acquiring certificates and/or storing/restoringTPM data for the ATM.

In an exemplary embodiment, if an ATM hard drive and/or the data on anATM hard drive is destroyed or otherwise corrupted, the described TPMconfiguration software and the ATM applications may be reinstalled onthe ATM by a technician servicing the machine. The TPM configurationsoftware may then be used to reinstall the TPM backup data correspondingto the ATM to return the ATM to a functional state. However, in theevent the motherboard including the TPM is replaced in the ATM, theabove described steps for acquiring ownership of the TPM, generatingsignature keys, acquiring corresponding certificates, and backing up thenew TPM data may be carried out to return the ATM to a functional state.

In an exemplary embodiment of an ATM that includes an EPP, the EPP maybe used to securely receive data (in addition to keys) used in theoperation of the ATM. For example, data such as ATM screen data usableto generate user interfaces through a display device of the ATM, may beprovided to the ATM from a host banking system. Examples of ATMs whichuse screen data are shown in U.S. application Ser. No. 11/169,315 filedon Jun. 28, 2005, which is hereby incorporated herein by reference. Toprevent such screen data from being accessed and/or modified by anunauthorized application or device, the screen data may be encrypted atthe host into a form which is capable of being decrypted by an EPP inthe ATM. For example, the screen data may be encrypted by the host usinga secret key such as a communication key known to the EPP. The computerof the ATM may include software operative to transfer the encryptedscreen data received from the host to the EPP and to cause the EPP todecrypt the screen data. The EPP and/or the software in the computer ofthe ATM may also be operative to cause the screen data to be encryptedagain using the TPM. The screen data encrypted using the TPM may then bestored in a data store until needed to generate a user interface screen.When at least a portion of the screen data is needed to generate a userinterface screen, the TPM may be used to decrypt at least the portion ofthe screen data. The decrypted screen data may then be used by thecomputer and/or a processor in the display device to produce an outputthrough the display device of the ATM, associated with a transactionfunction being performed by the ATM (e.g. dispensing cash).

For example in one embodiment, the display device may include aprocessor that is programmed to received encrypted screen data andcommunicate with the TPM to cause the encrypted screen data to bedecrypted prior to the processor of the display device using the screendata to generate a visual output. In a further embodiment, software inthe computer of the ATM may use the TPM to decrypt the screen data. Thedecrypted screen data may then be used by the software to generateinstructions through the operating system which cause a video graphicscontroller of the ATM to generate an output through a display device ofthe ATM. In this alternative embodiment, the video graphics controllermay correspond to the previously described protected video graphicscontroller. As a result, the communications between the operating systemand the protected video graphics controller may be encrypted through useof the TPM to prevent unauthorized access to and/or altering of theintended video signal produced by the video graphics controller.

In embodiments in which screen data is encrypted, or in embodiments inwhich the screen data is not encrypted, the ATM may require screen datato be digitally signed and the digital signatures authenticated prior tooutputting a user interface responsive to such screen data. Such screendata or other data may be signed with private key of the host. Such aprivate key may be associated with a public key incorporated in adigital certificate of the host. The host digital certificate may bestored in the EPP or stored in a certificate data store on the computerof the ATM. In one embedment, the processor of the EPP may use the hostpublic key to authenticate signed data such as screen data received fromthe host. In other embodiments, the TPM may use the host public key toauthenticate signed data received from a host.

As used herein, screen data corresponds to any instructions which areusable by the ATM to produce user interface outputs through an outputdevice of the ATM. Such output devices typically include a displaydevice. However, such output devices may also include sound outputdevices such as a sound system of the ATM. The sound output device mayinclude speakers and/or a headphone jack. Thus screen data may includeinstructions for generating both visual and audible outputs. Forexample, screen data may include instructions for generating the textand graphics which comprises a visual screen. Such instructions mayinclude HTML and XML. In addition screen data may include graphics filescorresponding to icons, images, bitmaps, gifs, and jpgs. Further screendata may include sound files such as wav, or mp3 files. Screen data mayalso include text which is flagged for being processed by speechsynthesizer hardware and/or software for use with generating verbalaudible outputs.

In addition to using the EPP to decrypt screen data received from a hostbanking system, in embodiments of the ATM the EPP may be used to decryptother types of data sent from a host. Such other types of data (besideskeys and screen data) may include markup language documents or othertypes of document used to configure and control the operation of theATM. Examples, of ATMs which use markup language documents received froma host to configure and operate an ATM are shown in U.S. applicationSer. No. 10/990,334 filed Nov. 16, 2004 which is hereby incorporatedherein by reference. As with the screen data, the other types ofinformation decrypted using the EPP may be encrypted again usingfeatures of the TPM and stored on the ATM for later use in operating themachine and devices in the ATM.

Although the previously described systems and method have been directedto an ATM that includes a TPM used to establish a TP, it is to beunderstood that in alternative embodiments, the previously describedsystems and methods of using a TPM may be provided in other types ofself service terminals in addition to ATMs. Examples of other types ofself service terminals which may include embodiments of the previouslydescribed TP may include kiosks, self check-out systems, and electronicvoting machines.

FIG. 11 shows an embodiment of a voting machine 810 which comprises a TP800 with a TPM 814 in operative connection with a computer processor 850of the voting machine. The voting machine may include protected inputand/or output devices 860 adapted for use with the TP to establishtrusted and secure communication channels between the processor and theinput and/or output devices of the machine. For example, the votingmachine may include a touch screen 862 that functions as both an inputdevice and output device. The TP may be operate to establish a trustedand secure channel for receiving encrypted touch screen inputs from thetouch screen. In addition, the voting machine may include a protectedvideo graphics controller which is adapted for use with the TP toestablish a trusted and secure channel for receiving data from theprocessor for outputting a user interface through the touch screen. Theembodiment of the video graphics controller may include video memory,for example, in which at least a portion of the video data storedtherein is encrypted and secure from modification by an unauthorizedcomponent such as a virus or worm.

In this described embodiment, the voting machine may include protectedapplets or NCAs, referred to herein as voting software components 822which are operative in the protected partition 832 of the TP. The votingsoftware components may be operative to cause the touch screen to outputa user interface with information representative of a voting ballot. Thevoting machine may also include a card reader 864 or other input devicewhich is operative to read ballot information from a portable memorydevice. Such a portable memory device, for example, may correspond to asmart card, flash memory card, or any other portable device whichincludes a data store for storing ballot information. The ballotinformation may include the precinct, political party or otherinformation for which the user with the card is authorized to castvotes.

The embodiment of the voting machine may include one or more secure datastores 880 which include at least one of curtained memory areas and/orsealed storage managed by the associated protected memory managementfeatures of the computer processor, associated chipsets, TPM, and/orprotected kernel of the voting machine TP.

In at least one of the secure data stores, the voting machine isoperative to store election information representative of the candidatesand issues capable of being voted on for one or more precincts,political parties or other groupings of election data. In an embodimentof the voting machine, the voting software components 822 of the votingmachine are responsive to the election information accessed from asealed storage of the machine and ballot information accessed from aportable memory device by the machine to cause the computer of themachine to generate a user interface through the touch screen whichshows each of the candidates and issues the user is authorized to castvotes.

In an embodiment of the voting machine, the card reader or other inputdevice for reading ballot information may correspond to a protectedinput/output device which is adapted for use with a TP to establish atrusted and secure communication channel with the processor of themachine. In an embodiment of the voting machine, the ballot informationstored on the portable memory device may be digitally signed and/orencrypted. An embodiment of the voting software components may beoperative to verify the digital signature associated with the ballotinformation and/or decrypt the ballot information prior to forming auser interface usable to cast votes.

In an embodiment of the voting machine, the voting software componentsmay be operative to receive the inputs from the touch screencorresponding to votes cast by users of the machine for and againstcandidates and issues displayed by the touch screen. The inputs receivedby the voting software components may also correspond to otherinformation associated with the voting process such as write incandidates. As used herein, such inputs are referred to as voterinputted information. In the embodiment of the voting machine, thevoting software components may be operative to securely store the voterinputted information associated with a plurality of user's of themachine into one or more secure data stores.

Embodiments of the voting machine may further include a printer 866. Thevoting software components may be operative to cause the printer tooutput a printed ballot with indicia representative of the ballotinformation and/or voter inputted information. In an embodiment of thevoting machine, the printer may be adapted for use with a TP toestablish a trusted and secure communication channel between the printerand the computer processor.

In further embodiments, the printer may be operative to direct printedballots into a ballot box or other storage chamber. Prior to depositinga printed ballot into a storage chamber, the printer may be operative toplace the printed ballot into a location which is viewable by the userthat provided the voter inputted information. The voting softwarecomponents may further be operative to prompt the user to confirm thatthe printed ballot is accepted. In response to receiving an inputrepresentative of the ballot being accepted, the voting softwarecomponents may be operative to cause the printer to move the ballot intothe storage chamber

In response to receiving an input representative of the ballot not beingaccepted, the voting software components may be operative to cause theprinter to mark the ballot with indicia representative of the ballotbeing designated as not accepted by the user. The printer may then beoperative to move the marked ballot into the storage chamber

In an embodiment of the voting machine, the voting software componentsmay be operative to enable the user through use of the touch screen tomodify the previously provided voter inputted information and print anew ballot with the printer. In an embodiment of the voting machine, thevoting software components may be operative to store voter inputtedinformation in more than one secure data stores managed by the TP. In anembodiment of the voting machine, a first secure data store maycorrespond to the curtained memory of the voting software component. Thecurtained memory may include voter inputted information for a currentballot being viewed by a user. When the user wishes to modify the voterinputted information, the voting software components may be operative tocause the touch screen to redisplay one or more user interface screensrepresentative of the previously provided voter inputted informationaccessed form the curtained memory associated with the voting softwarecomponent.

When the user provides an input to the machine indicating that theballot is accepted by the user, the voting software components of themachine may be operative to store the voter inputted information in atleast one second secure data store. The at least one second secure datastore may be operative to hold voter inputted information from aplurality of different users. In an embodiment of the voting machine,the at least one second secure data store may correspond to sealedstorage stored on a nonvolatile data store such as a hard drive or flashmemory card. In a further embodiment, the voting software components maybe operative to store the accepted voter-input information in two ormore secure data stores physically located on different data storedevices. The two different memory devices for example may correspond toa sealed storage on a hard drive and an encrypted file stored on aportable storage device such as a flash memory card. The voting softwarecomponents may also be operative to digitally sign the voter inputtedinformation that is stored in the encrypted file.

In an embodiment of the voting machine, when an election is completed,the portable storage device cards with the encrypted voter inputtedinformation may be removed from the machine and transported to a furthermachine capable of accumulating votes for an election from a pluralityof different voting machines. In an embodiment of the voting machine,the further machine may correspond to another voting machine whichincludes a voting software component with one or more cryptographic keyswhich are capable of decrypting and authenticating the voter inputtedinformation from a plurality of different portable storage devices.

In further embodiments of an ATM or other self service terminal a TPMmay be used to perform cryptographic calculations associated withenabling a user of the terminal to digitally sign electronic documents(e.g. loan papers, contracts, deeds, mortgages) visually displayedthrough a display device of the ATM. Examples of ATMs and other kinds ofterminals capable of being used to digitally sign electronic documentsare shown in U.S. patent application Ser. No. 09/683,942 filed Mar. 5,2002, which is hereby incorporated herein by reference. Examples ofcryptographic functions performed using a TPM to digitally signelectronic documents for users may include one-way hash functions suchas SHA-1 or MD5.

In an embodiment of the described terminal, the software operating inthe terminal may access the TPM to generate a hash or digest of anelectronic document displayed to a user through a display device of theterminal. This hash may be encrypted by a remote server, or otherprocessor in communication with the terminal, to form a digitalsignature which is attached to or otherwise associated with theelectronic document. In this described embodiment, the private key usedto encrypt the hash of the electronic document may be securely stored bythe remote server in association with a financial account number (e.g.credit/debit account number), driver's licence number, and/or nationalID card number associated with the user. Such a private key may beaccessed for use with encrypting the hash of the electronic documentresponsive to the terminal reading the account number associated withthe user from a card of the user and responsive to the user providing ininput of a password such as a PIN into an input device of the terminal.

In the embodiments described above, reference has been made to thegeneration or use of numbers such as random numbers, passwords, PINs,and hashes. Such numbers may correspond to a series of characterscomprised of only numeric digits (e.g. 0-9). However it is to beunderstood that depending on the procedure for generating, inputting,and or otherwise using the described numbers in the particularembodiment, such numbers may also include: alphanumeric characters (e.g.a-z, A-Z and 0-9), characters from different alphabets and languages,characters corresponding to symbols and/or non-printable characters. Asused herein, the reference to numbers may in one or more embodimentsencompass at least one character capable of being recognized ormanipulated by a computer processor.

Also as used herein, reference is made to hashing data to form a hash ordigest. Such hashes or digests correspond to the output of a one wayhash function (e.g. MD5 and SHA-1) operating on the data. Also as usedherein, reference is made to various symmetric (e.g. DES, AES) andasymmetric (RSA) encryption and decryption algorithms and keys. However,is to be understood that the cryptographic software and hardwareemployed by embodiments described herein may use other one-way hasfunctions and encryption/decryption algorithms depending on the desiredlevel of cryptographic security, and the processing capabilities of thehardware employed for the embodiment.

Computer software instructions used in operating the automated bankingmachines and connected computers may be loaded from computer readablemedia or articles of various types into the respective computers. Suchcomputer software may be included on and loaded from one or morearticles such as diskettes, CDs, DVDs, flash memory devices. Suchsoftware may also be included on articles such as hard disk drives,tapes or ready only memory devices. Other articles which include datarepresentative of the instructions for operating computers andprocessors of devices in the manner described herein are suitable foruse in achieving operation of automated banking machines and systems inaccordance with embodiments described here.

Thus the new automated banking machines and other self-service terminalsdescribed herein achieve one or more of the above stated objectives,eliminates difficulties encountered in the use of prior devices andsystems, solves problems and attains the desirable results describedherein.

In the foregoing description certain terms have been used for brevity,clarity and understanding; however, no unnecessary limitations are to beimplied therefrom because such terms are used for descriptive purposesand are intended to be broadly construed. Moreover, the descriptions andillustrations herein are by way of examples and the invention is notlimited to the exact details shown and described.

In the following claims, any feature described as a means for performinga function shall be construed as encompassing any means known to thoseskilled in the art to be capable of performing the recited function, andshall not be limited to the features and structures shown herein or mereequivalents thereof. The description of the embodiment included in theAbstract included herewith shall not be deemed to limit the invention tofeatures described therein.

Having described the features, discoveries and principles of theinvention, the manner in which it is constructed and operated, and theadvantages and useful results attained; the new and useful structures,devices, elements, arrangements, parts, combinations, systems,equipment, operations, methods and relationships are set forth in theappended claims.

1. Apparatus comprising: an automated banking machine that operatesresponsive to data read from data bearing records to cause financialtransactions, including: a plurality of devices including: a card readeroperative to read card data on user cards corresponding to financialaccounts; a cash dispenser; at least one computer in operativeconnection with the plurality of devices, wherein the at least onecomputer includes at least one data store and at least one communicationdevice that is operative to communicate with at least one portablestorage device placed in operative communication with the at least onecommunication device; a housing, wherein the at least one computer andthe plurality of devices are in operatively supported connection withthe housing; wherein the at least one computer is operatively configuredto produce a decrypted at least one first portion of an operating systemaccount password through communication with the portable storage device,wherein the at least one computer is operatively configured to access atleast one second portion of the operating system account password fromthe data store in the automated banking machine; wherein the at leastone computer is operatively configured to generate the operating systemaccount password responsive to the at least one first portion and the atleast one second portion of the ATM account password; wherein the atleast one computer is operatively configured to log into the operatingsystem login account of the at least one computer using the generatedoperating system account password.
 2. The apparatus according to claim1, wherein the at least one computer includes a trusted platform module(TPM) in operatively supported connection with the at least one computerinside the housing.
 3. The apparatus according to claim 2, wherein theat least one computer is operatively configured to cause the TPM todecrypt the at least one first portion of the operating system accountpassword.
 4. The apparatus according to claim 3, wherein the TPM iscompliant with a Trusted Computing Group TPM 1.2 Specification.
 5. Theapparatus according to claim 1, wherein in the operating system loginaccount corresponds to an administrative account.
 6. The apparatusaccording to claim 1, wherein the login account has sufficientprivileges to enable a user to access at least one software componentoperative to service the cash dispenser.
 7. The apparatus according toclaim 1, wherein the communication device includes a USB port.
 8. Theapparatus according to claim 7, wherein the automated banking machineincludes at least one input device in operative connection with the atleast one computer, wherein the at least one computer is operativelyconfigured to communicate a personal identification number (PIN)received through operation of the input device to a cryptographic tokenplaced in operative connection with the USB port, in order to acquireaccess to the at least one first portion of the operating system accountpassword from the cryptographic token.